System and method for dynamic uploading and execution of applications and drivers between devices

ABSTRACT

A methodology for dynamic (i.e., run-time) uploading and execution of applications and drivers between devices (e.g., between “client” device and one or more (host) devices), in a fully automated manner, is described. The device which is to be hosted (e.g., the “client” device) initially probes its environment to determine which device or devices it is attached to (e.g., the “host” device(s)). Once it has correctly discerned the relevant host or target device(s), the client device includes the capability of immediately sending out (i.e., uploading) a particular driver or application (i.e., object or file of interest) for placement, and ultimately execution, at the host device. Once the particular object or file of interest has been “injected” into the host device and is executing, the client device may simply revert to a “listening mode” in which it waits to be told what to do (i.e., receive commands from the application or driver which is now executing at the host device). This approach is particularly well-suited for devices which serve as “add-on” devices (clients) to other devices (hosts) that are “smarter,” for instance, including more processing capability and/or memory. In this scenario, the client device enters into a dialog with a device with more resources for the purpose of harnessing the resources of the host device for operating the client or add-on device. The client device is, using this approach, able to start running (i.e., driver-directed operation) immediately upon attachment to a host device that can be identified.

RELATED APPLICATIONS

[0001] The present application is related to and claims the benefit ofpriority of the following commonly-owned non-provisional application(s):application Ser. No. 09/660,531 (Docket No. LS/0005.00), filed Sep. 13,2000, entitled “System and Method for Dynamic Uploading and Execution ofApplications and Drivers between Devices”, of which the presentapplication is a Continuation-in-part application thereof. The presentapplication is also related to the following commonly-ownedapplication(s): application Ser. No. 09/537,001 (Docket No. LS/0001.02),filed Mar. 28, 2000, entitled “Improved Digital Camera Device andMethodology for Wireless Progressive Transmission of Digital Images”.The disclosures of each of the foregoing applications are herebyincorporated by reference in their entirety, including any appendices orattachments thereof, for all purposes.

COPYRIGHT NOTICE

[0002] A portion of the disclosure of this patent document containsmaterial which is subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument or the patent disclosure as it appears in the Patent andTrademark Office patent file or records, but otherwise reserves allcopyright rights whatsoever.

BACKGROUND OF THE INVENTION

[0003] The present invention relates generally to system and methodologyfor dynamic or run-time uploading of an application or driver ofinterest from a first device to a second device, upon connecting the twodevices together, and thereafter executing the application or driver atthe second device.

[0004] Today, a multitude of different types of devices may beintermittently connected together for a particular user purpose. Forexample, many of the digital camera devices available today include thecapability of connecting to different types of modules. Examples includemodules that can transmit the camera's image data, modules that canprint the image data, and modules that can display the image data, justto name a few. In order to support meaningful dialog between suchdevices, it is necessary to provide a mechanism that allows the cameradevice to identify what target or host device it is connected to andvice versa (i.e., identifying the camera device to the target device),as well as a mechanism that allows a program (e.g., driver) to run onthe target device so that the target device may correctly communicatewith the camera device. For example, a driver program or applicationexecuting at the target device can issue appropriate commands to thecamera device for determining what image data (photos) exist on thecamera device, so that they may be offloaded onto the target device forviewing, printing, or storing.

[0005] Generically speaking, a “driver” is a software program thatcontrols a device, typically allowing that device to interoperate withother devices. For example, a printer driver allows a correspondingprinting device to interoperate with software programs operating on adesktop computer that the printer is connected to. A driver acts like atranslator between the device and programs that use the device. Devicestypically include their own set of specialized commands that only itsdriver knows. At the same time, most programs prefer to access devicesby using generic commands. The driver, therefore, may serve as ago-between by accepting generic commands from a program and thentranslates them into specialized commands for the device. Many drivers,such as keyboard drivers, come with a user's operating system. For otherdevices, the system is required to load a new driver when the userconnects the device to his or her computer.

[0006] In the early days of personal computing, a user was required tomanually install the appropriate driver for any new device that the userconnected to his or her computer. More recently, that manual approachhas been abandoned in favor of a “plug and play” approach. As an examplefamiliar to PC users, today “plug and play” PCI bus cards (e.g., videographics cards and sound cards) include code within them that triggersloading at operating system startup of a particular driver. “PCI” is anacronym for Peripheral Component Interconnect, a local bus standarddeveloped by Intel Corporation. If the operating system (e.g., Windows98) is able to locate a copy of the driver for a newly-installed PCI buscard, the driver is automatically loaded by the operating system tosupport operation of that PCI bus card. Note in particular with thisapproach, however, the host device (e.g., PC) must either alreadypossess a copy of the relevant driver (e.g., in the Windows “cabinet”files) or the user is required to manually furnish the driver (e.g., byinserting a floppy disk or CD including the relevant driver).

[0007] In practice, the approach has been less than “plug and play.”Often, the operating system is unable to recognize a newly-installeddevice or, worse, “crashes” (i.e., hangs) while attempting to uncovernearly-installed devices. Another problem is that, even if anewly-installed device is recognized, the operating system is unable toautomatically locate a copy of an appropriate driver for that device. Inthat situation, the system resorts to prompting the user to indicatewhere a copy may exist, and in some cases requires the user to manuallyinstall and configure the appropriate driver. Given these and otherproblems that have beset “plug and play,” the approach has been giventhe more dubious title of “plug and pray” by the computer industrypress. Nevertheless, “plug and play” architecture represents perhaps thefirst serious attempt to provide some degree of automated driverinstallation.

[0008] With the ever-increasing popularity of Internet-based computing,it is not surprising that others have turned to the Internet in aneffort to provide dynamic loading of drivers and other applications. Forinstance, as the result of using a Web browser, a user may trigger theautomatic downloading of a particular driver. In this example, thedriver is transferred from a Web server to the user's PC using HTTPprotocol. HTTP or “HyperText Transfer Protocol” is the underlyingprotocol used by the World Wide Web. HTTP defines how messages areformatted and transmitted, and what actions Web servers and browsersshould take in response to various commands. Using HTTP in the Internetenvironment, “plug-in” functionality can be provided that supports somedegree of automated driver or application installation and startuploading. A plug-in is a software (or hardware) module that adds aspecific feature or service to a larger system. For example, there arenumber of plug-ins for the Netscape Navigator browser that enable it todisplay different types of audio or video messages.

[0009] Despite the multitude of approaches available for automatingdriver installation and startup loading, current approaches havesignificant shortcomings when attempting to connect two devicestogether. Many different types of devices exist and, expectedly, havedisparate characteristics as to how they initially respond to acommunication (between devices). In particular, many devices today“speak differently” (i.e., employ different communication protocols),thus preventing several of these devices from communicating with oneanother for purposes of device identification and driver-loading. Forinstance, the above plug-in approach basically assumes that all devicesspeak the same language, such as using HTTP commands over TCP/IP(Transmission Control Protocol/Internet Protocol, the suite ofcommunications protocols used to connect hosts on the Internet).However, even the underlying communication infrastructure—TCP/IP—may noteven be running initially on a particular target or host device ofinterest. Thus, one may not even rely on TCP/IP being available, atleast initially, on a particular target device. (For an introduction toTCP/IP, see e.g., RFC 1180: A TCP/IP Tutorial, the disclosure of whichis hereby incorporated by reference. A copy of RFC 1180 is currentlyavailable at ftp.Iftp.isi.edu/in-notes/rfc1180. txt).

[0010] To date, these shortcomings have yet to be adequately addressed.As a result, realization of a completely transparent “plug and play”architecture has remained elusive. What is needed is an approach where afirst device (e.g., digital camera device) may automatically upload andinstall an application or driver of interest to a second device (e.g.,handheld computing device, that may “host” the digital camera device),upon the two devices being connected together. The present inventionfulfills this and other needs.

SUMMARY OF THE INVENTION

[0011] A methodology for dynamic (i.e., run-time) uploading andexecution of applications and drivers between devices (e.g., between“client” device and one or more (host) devices) in an automated manneris described. The device which is to be hosted (e.g., the “client”device) initially probes its environment to determine which device ordevices it is attached to (e.g., the “host” device(s)). Once it hascorrectly discerned the relevant host or target device(s), the clientdevice includes the capability of immediately sending out (i.e.,uploading) a particular driver or application (i.e., object or file ofinterest) for placement, and ultimately execution, at the host device.Once the particular object or file of interest has been “injected” intothe host device and is executing, the client device may simply revert toa “listening mode” in which it waits to be told what to do (i.e.,receive commands from the application or driver which is now executingat the host device). In the currently-preferred embodiment, a digitalcamera device serves as a “client” device, which may connect to avariety of “host” devices (e.g., cellular phone, PDA (Personal DigitalAssistant) handheld device, or the like).

[0012] The overall method or process of the present invention may besummarized as follows. The process gets underway upon the establishmentof a connection (wireless or wireline) between a client device and ahost device; the connection may be permanent or temporary. Starting withdefault registry information stored in a configuration registry, theclient device probes for any host devices. This task falls specificallyon a PHY (physical) manager. Based on the information uncovered by thisprobing, the registry is updated, with information describing discoveredhost devices and corresponding communication information relevant toeach such discovered host device. As part of this step, the PHY managerwill ensure TCP/IP connectivity to each such host device.

[0013] Now, the method may proceed with injection of the application ordriver (or other executable object of interest) into the host device(s).The method may examine the registry for determining each host devicethat is connected, as this will determine what specific task(s) must beundertaken for performing injection (i.e., to inject an appropriateapplication or driver into each such host device). A TCP/IP session isestablished with the host device, for the specific purpose of injectingthe file or object of interest (e.g., application or driver). The fileis opened on the client device; as part of this process, a client-sidefile handle is obtained. From the perspective of the client device, thefile is simply a binary object to be injected. The specific relevance ofthe file will be uncovered at the host device, when the file isultimately executed at the host device. Having obtained a valid filehandle for the file to be injected, the method may now proceed topackage the file contents for transmission to the host device. In thecurrently-preferred embodiment, the XML protocol is employed for thispackaging. Now, using TCP/IP, the packaged file may be transmitted(streamed) from the client device to the host device. In conjunctionwith this step, a host-side file handle is returned to the clientdevice.

[0014] At this point, the method is now ready to trigger execution ofthe just-injected application or driver at the host device. Using thehost-side file handle, the method instructs the host to now execute thejust-injected application or driver. Host-side execution may requirehost-specific operations. In the straightforward case, the host issimply instructed to begin execution of the application or driver. Ifthe host device does not support that functionality, however, executionof the application or driver may be accomplished through indirect means,such as instructing the host to “restart” itself and thereupon executethe application or driver (e.g., by placing the application or driver ina location where the host will automatically load it for execution uponstartup). Thereafter, operation between the client and host devicescontinues as specified in the now-executing application or driver, whichitself in turn may unpackage other drivers for execution. In a typicaloperation, the application or driver would issue particular commands tothe client device, for instance, requesting that the client devicetransmit particular information that is to be processed by the hostdevice, such as uploading digital photographs from the client device tothe host device, for wireless transmission by the host device to yetanother device (e.g., server computer).

[0015] This approach is particularly well-suited for devices which serveas “add-on” devices (clients) to other devices (hosts) that are“smarter,” for instance, including more processing capability and/ormemory. In this scenario, the client device enters into a dialog with adevice with more resources for the purposes of harnessing the resourcesof the host device for operating the client or add-on device. The clientdevice is, using this approach, able to start running (i.e.,driver-directed operation) immediately upon attachment to a host devicethat can be identified.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016]FIG. 1A is a block diagram illustrating a device, in the preferredembodiment a digital camera device, that is suitable for implementingthe present invention.

[0017]FIG. 1B is a block diagram illustrating a digital computer thatmay interoperate with the digital camera device of FIG. 1A.

[0018]FIG. 2 is a block diagram of a software system suitable forcontrolling the computer of FIG. 1B.

[0019]FIG. 3 is a block diagram of an application/driver uploader systemof the present invention, which is embodied in the digital camera deviceof FIG. 1A.

[0020] FIGS. 4A-B are flowcharts illustrating the overall methodology ofoperation for the application/driver uploader system of FIG. 3.

DETAILED DESCRIPTION OF A PREFERRED EMBODIMENT

[0021] The following description will focus on the presently-preferredembodiment of the present invention, which operates in an environmenttypically including a variety of computing or information-storingdevices (e.g., desktop computers, server computers, and portablecomputing devices), that are occasionally or permanently connected toone another where device-specific driver support is desired. Inparticular, the following description focuses on an embodiment of thepresent invention in a digital camera device, the currently-preferredembodiment, which may be occasionally connected to a multitude ofdifferent “host” devices, such as a Palm™ handheld computer or acellular phone. However, those skilled in the art will appreciate thatthe present invention may be embodied in practically any device that isintended to be connected to another device (or devices). Further, thedescription focuses on implementation of portions of the invention in aconnected environment including computers, such as an IBM-compatiblecomputer running under Microsoft® Windows 2000, with Internet support.The present invention, however, is not limited to any particular oneapplication or any particular environment. Instead, those skilled in theart will find that the system and methods of the present invention maybe advantageously embodied on a variety of different platforms,including Macintosh, Linux, BeOS, Solaris, UNIX, NextStep, and the like,as well as special-purpose operating systems (e.g., digital cameraoperating systems). Therefore, the description of the exemplaryembodiments which follows is for purposes of illustration and notlimitation.

[0022] Basic System

[0023] A. Digital camera hardware

[0024]FIG. 1A is a block diagram illustrating a basic image capturingand recording system 100 suitable for implementing the presentinvention. For purposes of illustration, the following focuses onimplementation of the system 100 as a digital camera. However, as notedabove, for purposes of implementing the methodology of the presentinvention, the system 100 may also be implemented in a variety of otherdevices that are intended to be connected (including, occasionallyconnected) to yet other devices.

[0025] As shown in FIG. 1A, the system 100 includes a Sensor 101, aShutter Actuator 103, an Image Processor 102, an Image (DRAM) Memory104, a (Central) Processor 106, a Keypad and Controls 108, a ProgramCode Flash Memory 107, a (System) Memory 105, a Direct View Display orViewfinder 109, a Hot Shoe Interface 110, and a “Digital Film” FlashMemory 111. As illustrated, these various components communicate withone another using a bus architecture including, for instance, an AddressBus, a Data Bus, and an I/O (Input/Output) Bus.

[0026] The system 100 employs the Sensor 101 for basic image capture.The Sensor 101 operates, in essence, by capturing light and transformingthat into electrical voltage levels. A suitable sensor is available froma variety of vendors, including VLSI Vision, Motorola, and Toshiba. In apreferred embodiment, the Sensor 101 includes, for example, a 1280×1024color CMOS sensor, such as a VLSI Vision VVL 6801 CMOS sensor. However,other sensor technology is suitable, including CCD sensors.

[0027] The Sensor 101 must, of course, be part of a larger assembly tooperate. Specifically, the Sensor 101 operates in conjunction with alens assembly (not shown), or other optics to focus an image onto thesensor. The optics themselves are controllable, for instance, using aconventional aperture, focus, and shutter control mechanisms. Thecurrently-preferred embodiment uses an 18 mm fixed-focal length,fixed-aperture lens assembly to provide a broad depth of field. The lensassembly employs two manual slide controls, a macro lens control, and anexposure control. The macro control switches from normal to close-upmode by sliding a macro lens in and out of the lens assembly to providenormal or extreme close-up capability. The exposure control switchesfrom normal to bright light by sliding a neutral gray filter in and outof the lens assembly. Aside from choosing normal or bright light, andnormal or close-up mode, the camera requires no manual focusing, shutterspeed or aperture adjustment. Operation is as simple as point and shoot.The Sensor 101, on the other hand, operates under control of the ImageProcessor 102, which will now be described.

[0028] The Image Processor 102, which basically operates as a statemachine, provides overall control for the Sensor 101. In operation, theImage Processor 102 controls the Sensor 101 by, in effect, telling itwhat to do and when. For instance, the Image Processor 102 issues timingsignals to the Sensor 101 for indicating how the Sensor 101 shouldrecord and stream out image data. Further, the Image Processor 102provides general Input/Output (I/O) control that allows one tocoordinate control of the sensor with other electromechanicalperipherals, such as a shutter, lens aperture, or the like.

[0029] Actual implementation of the Image Processor 102 itself may beaccomplished in a variety of different ways. For a microprocessor-basedimplementation, for instance, the Image Processor 102 may be implementedas a microprocessor (e.g., PowerPC 823 microprocessor, available fromMotorola, Inc. of Schaumburg, Ill.) with DSP (digital signal processing)logic blocks, memory control logic blocks, video control logic blocks,and interface logic. Alternatively, the Image Processor 102 may beimplemented as a “camera on a chip(set)” using, for instance, a SierraImaging Raptor I or II chipset (available from Sierra Imaging, Inc. ofScotts Valley, Calif.), a Sound Vision Clarity 1 or 2 chipset (availablefrom Sound Vision, Inc. of Framingham, Mass.) or similar chipset thatintegrates a processing core with image processing periphery. in apreferred embodiment, the Image Processor 102 preferably supportshardware implementation of a wavelet-transform engine complete with awavelet-transform filter bank, so that the wavelet-transform process maybe pipelined through a series of dedicated hardware gates (instead ofexecuted as a sequence of software instructions repeatedly loaded andprocessed by a general-purpose microprocessor).

[0030] The Image Processor 102 is not a stand-alone part but, instead,relies on the (Central) Processor 106 for control instructions. TheImage Processor 102 sits on the Address and Data Buses and is accessibleby the Processor 106 through a series of registers. In this manner, theProcessor 106 may instruct the Image Processor 102 what to perform andwhen. For instance, the Processor 106 may instruct the Image Processor102 to turn on the Sensor 101, to capture an image at the Sensor 101,and to execute the wavelet transform. Therefore, the Image Processor 102is very much a facilitator but is not in and of itself a controller forthe system.

[0031] The Shutter Actuator 103 is a simple, generic component forcontrolling light exposure on the Sensor 101. Depending on the behaviorof the actual sensor employed, the Shutter Actuator 103 may not even benecessary. In particular, the Shutter Actuator 103 is employed in thoseinstances where the Sensor 101 requires a black reference. In such anembodiment, the Shutter Actuator 103 is an electromechanical interfacecoupled to a solenoid which, when the interface responds to a particularlogic level, triggers an open/close cycle of a mechanical shutter. Themechanical shutter, which serves to selectively block light entering thelens assembly of the camera, may be of a conventional design availablefrom a variety of suppliers. A suitable supplier includes, for instance,Sunex, Inc. of Carlsbad, Calif.

[0032] The Image Memory (DRAM) 104 serves to store the image capturedfrom the sensor. The Sensor 101 itself does not “store” the image thatit captures. Therefore, the Image Memory 104 is an image capture andin-place transform (frame) buffer. This memory is controlled by theImage Processor 102 and can be shut off when not in use for power savingpurposes. During basic operation of the camera, the captured image istransferred directly into the Image Memory 104, using a sample/transfertechnique. In order to make this efficient, the process is controlled bythe Image Processor 102 in a manner somewhat akin to DMA (direct memoryaccess) transfer employed on desktop computers. Here, the ImageProcessor 102 functions as a state machine which simply samples andtransfers information from the Sensor 101 to the Image Memory 104. Inthe presently-preferred embodiment, the Image Memory 104 comprisesconventional DRAM (dynamic random-access memory) memory available from avariety of vendors, including, for instance, Toshiba, Micron, Hitachi,Samsung, and others. A size of about 4 MB (megabyte) or more is suitablefor this component.

[0033] The next several components discussed, which may be viewed ascomponents hanging off of the Address and Data Buses of the Processor106, are typical components that one would ordinarily expect to findwhen implementing a data processing device; collectively, thesecomponents may be viewed as a computer embedded in the camera. Forexample, these components include the previously-mentionedgeneral-purpose microprocessor (Processor 106) coupled to memory (SystemMemory 105 and Program Code Flash Memory 107). The Working or SystemMemory 105 is the general working or scratchpad memory for the Processor106. This memory is used for storing program-created variables, stacks,heap(s), and the like. In the presently-preferred embodiment, the SystemMemory 105 comprises static RAM (e.g., SRAM), which is also availablefrom a variety of vendors. A size of about 128 KB (kilobyte) or more issuitable for this purpose. The Program Code Flash Memory 107, on theother hand, comprises 1 MB of directly-addressable flash storage thatholds the operating system and embedded software, that is, the programcode comprising the instructions that the processor must execute tooperate. The flash memory, which may be conventional flash memory thatis available from a variety of vendors, need not be of the removabletype, as the Program Code Flash Memory 107 is not intended to be removedfrom the system by the camera user.

[0034] The Processor 106 itself, in the presently-preferred embodiment,comprises a 32-bit RISC ARM Processor designed by ARM Limited ofMaidenhead, UK. ARM licenses its designs to semiconductor partners formanufacture, supply, and support; for a list of ARM licensees, see e.g.,http //www.arm.com/Partners/. The ARM processor has an efficientinstruction set that is ideal for performing cyclical functions quiterapidly and includes sufficient bandwidth for transferring large amountsof data quickly (e.g., for performing Huffman coding on a large amountof data). Additionally, the processor is a dedicated processor, withoutthe overhead of a substantial number of peripherals. These features makethe processor attractive for use in a digital camera embodiment.

[0035] For a camera embodiment, the device will, in general, be expectedto include an interface that is capable of receiving input from users.Keypad and Controls 108 are conventional inputs that support user input.Similarly, the Direct View Display (“Viewfinder”) 109 is a direct viewLCD (liquid crystal display) that provides feedback to the user orcamera operator. During photography mode, the Viewfinder 109 replacesthe plastic viewfinders and LCD panels found on most digital cameras andprovides the most accurate real-time representation of the scenevisualized by the sensor. The Viewfinder 109 overlays simple icons ontothe image to indicate the status of various camera settings. TheViewfinder 109 fits inside an eyepiece which keeps sunlight out andallows the operator to visualize the scene in any lighting conditions.During preview mode, the Viewfinder 109 shows previews of the capturedphotos and allows the operator to delete unwanted photos or tag photosfor wireless transmission. Thus for a camera embodiment, the Viewfinder109 is used to provide a representation of the image that is beingcaptured, in preview and/or post-capture fashion.

[0036] In order to provide the display image to the Viewfinder 109, theSensor 101 is subsampled at a rate to create a version of the imageappropriate for display. During preview processing, the systemcontinuously captures the sensor mosaic and sub-samples the resultingmosaic for preview purposes. A histogram of the sampled luminosity isfed into a “linearization” filter to produce a balanced dynamic rangefor best optical perception. The scaled and “linearized” image is thendisplayed on the viewfinder module. The histogram data is then adjustedto match the preview image for use in linearizing the next image. Thecycle is repeated continuously to provide a real-time viewfindermechanism. The Viewfinder 109 itself typically operates in conjunctionwith a display controller and a frame buffer (not shown), both of whichmay be integrated within the display component itself.

[0037] Both the Keypad and Controls and Display components, which may beconventional in nature, interface directly with the Processor 106through general I/O (e.g., I/O Bus). Typically, such devices communicatewith the microprocessor through means of interrupt requests (IRQ). Boththe Keypad and Controls and Display components are available from avariety of vendors. Examples include Sharp, Toshiba, Citizen of Japan,Samsung of South Korea, and Hewlett-Packard of Palo Alto, Calif. Morecustomized displays are available from Displaytech, Inc. of Longmont,Colo. For an embodiment that does not need to interact with users, suchas a surveillance camera, the foregoing components may be eliminated.

[0038] Additionally for a camera embodiment, it is desirable for thedevice to include an interface for standard peripheral devices, such asa detachable flash device. This may be provided by Hot Shoe (Accessory)Interface 110, which is a general I/O port that may comprise a serialinterface of a conventional design that the camera uses to interface toits accessories via the Hot Shoe Interface. In this manner, a flashaccessory can be clipped onto the camera via the Hot Shoe Interface foradded illumination.

[0039] The Hot Shoe Interface 110 combines a Serial Peripheral Interface(SPI) with a multiplexed I/O bus which provides a plug-and-playinterface to a family of accessories. These accessories may include, inaddition to a flash unit, a wireless holster for cellular (e.g.,Motorola) phones, extra film backs for compatibility with format digitalfilm (e.g., Sony Memory Stick or SmartMedia), a USB cradle, an RJ-11modem cradle, a wireless cellular module, extender cables, and the like.In the currently-preferred embodiment, the interface is based on theI²C-standard serial interface, which supports logic allowing the deviceto sense I²C-compatible devices that are attached to the port. I²C,which stands for Inter IC Communication, is a serial bi-directionalcommunication protocol created by Philips Semiconductor (subsidiary ofPhilips Electronics, based in The Netherlands) and is used forcommunication between integrated circuits. Most systems have one masterand several slaves that communicate using only two wires. Every devicehas its own identification code. If that code is sent by the master onlythat device will respond with an acknowledgement. After theacknowledgement, the data to be communicated is sent or received by themaster. Further information about the I²C communication protocol isavailable from Philips Electronics of The Netherlands. As with theKeypad and Controls 108 and Direct View Display or Viewfinder 109, theHot Shoe Interface 110 itself is not required for implementing the imagecapturing and processing methodology of the present invention. In thespecific embodiment of a consumer product such as a camera, though,these components typically would be included.

[0040] The system 100 includes Digital Film Flash Memory 111, whichserves as the “digital film” for the system for storing compressedimages. The Flash Memory 111 may comprise available flash memoryremovable media, such as CompactFlash, DataFlash, and Sony Memory Stick,typically in a 16 MB or larger size. Available vendors for flash memoryinclude, for example, SanDisk of Sunnyvale, Calif. or Sony of Japan.Alternatively, the Flash Memory 111 may be affixed directly (i.e.,non-removable) to the system 100. In such an embodiment, the additionalbulk associated with a removable media cartridge holder and itsaccompanying interface may be avoided. Those skilled in the art willappreciate that the system 100 may incorporate other non-volatile memoryconfigurations and designs that readily accommodate the image captureand processing methodology of the present invention. In general, for aconsumer device embodiment, one should choose media that accommodates onthe order of 100 compressed images or more.

[0041] The camera embodiment is powered by a single CR-123 lithiumbattery (not shown), provided with instant-on capability. Due in part tothe distributed image processing approach of the present invention(presented below), the camera has significant power savings over othercamera designs. This gives the device not only a size and weightadvantage over other cameras but also a battery life advantage.

[0042] For connectivity, the system includes a wireless holster, a USBcradle, and a modem cradle. The wireless holster physically connects thecamera to a cellular phone (e.g., Motorola cellular phone) andinterfaces the Hot Shoe Interface to the phone's external accessoryplug. The camera can be easily pulled out of the holster for use andclipped back in for transmission. Detection of the holster and phonesignal is automatic to allow for hands-free transmission and there is norisk of corruption due to interruption by either loss of signal orunclipping. The camera clips into the USB cradle through the AccessoryHot-Shoe Interface 110 to provide rapid photo interchange to a personalcomputer equipped with a standard USB port. The USB cradle acts as a USBslave device and therefore requires no batteries or power supply foroperation and instead draws its power from the PC. The camera can alsoclip into a modem cradle through the Hot Shoe Interface. The modemcradle allows the camera to transmit images to a PhotoServer module(operating on system 150, described below) via a land line connection(e.g., 33.6 KBps) via a standard RJ-11 phone jack. The modem cradle ispowered by the battery in the camera.

[0043] The specifications for the currently-preferred camera embodimentmay be summarized as follows. TABLE 1 Miniature Wireless Digital CameraSpecifications: Sensor: 1.3 Mega-Pixel Color CMOS Optics: 18 mm FixedFocal Length, Fixed Aperture Exposure Control: Automatic, Macro Mode,Indoor/Outdoor Mode Processor: ARM 32-bit RISC Chipset: Image Processor(Lightsurf PhotonOne) Memory: 4 Mbytes DRAM + 128 Kbytes SRAM DigitalFilm: 16 Mbytes Internal Flash Film File Format: Progressive PhotographFormat (PPF) Wireless Protocol: Communication protocol, such aspacket-based TCP/IP, WAP, or the like Battery: CR-123 AccessoryInterface: Accessory Hot-Shoe Accessories: Flash Unit, Extra Film Back,Motorola Cellular Holster, USB Cradle, Modem Cradle

[0044] B. Basic computer hardware (e.g., for computers that may “host”add-on devices)

[0045] Portions of the present invention may be implemented on aconventional or general-purpose computer system, such as anIBM-compatible personal computer (PC) or server computer that may hostthe above-described digital camera device (e.g., via USB or RS-232connectivity). FIG. 1B is a very general block diagram of anIBM-compatible system 150. As shown, system 150 comprises a centralprocessor unit(s) (CPU) 151 coupled to a random-access memory (RAM) 152,a read-only memory (ROM) 153, a keyboard 156, a pointing device 158, adisplay or video adapter 154 connected to a display device 155, aremovable (mass) storage device 165 (e.g., floppy disk), a fixed (mass)storage device 166 (e.g., hard disk), a communication port(s) orinterface(s) 160, a modem 162, and a network interface card (NIC) orcontroller 161 (e.g., Ethernet). Although not shown separately, areal-time system clock is included with the system 150, in aconventional manner.

[0046] CPU 151 comprises a processor of the Intel Pentium® family ofmicroprocessors. However, any other suitable microprocessor ormicrocomputer may be utilized for implementing the present invention.The CPU 151 communicates with other components of the system via abi-directional system bus (including any necessary I/O controllercircuitry and other “glue” logic). The bus, which includes address linesfor addressing system memory, provides data transfer between and amongthe various components. Description of Pentium-class microprocessors andtheir instruction set, bus architecture, and control lines is availablefrom Intel Corporation of Santa Clara, Calif. Random-access memory 152serves as the working memory for the CPU 151. In a typicalconfiguration, RAM of sixteen megabytes or more is employed. More orless memory may be used without departing from the scope of the presentinvention. The read-only memory (ROM) 153 contains the basicinput/output system code (BIOS)—a set of low-level routines in the ROMthat application programs and the operating systems can use to interactwith the hardware, including reading characters from the keyboard,outputting characters to printers, and so forth.

[0047] Mass storage devices 165, 166 provide persistent storage on fixedand removable media, such as magnetic, optical or magnetic-opticalstorage systems, flash memory, or any other available mass storagetechnology. The mass storage may be shared on a network, or it may be adedicated mass storage. As shown in FIG. 1B, fixed storage 166 stores abody of program and data for directing operation of the computer system,including an operating system, user application programs, driver andother support files, as well as other data files of all sorts.Typically, the fixed storage 166 serves as the main hard disk for thesystem and stores application software implementing a PhotoServercomponent (PhotoDesktop, when implemented on a desktop computer), whichmay operate to process images uploaded from digital cameras (e.g.,digital camera device 100).

[0048] In basic operation, program logic (including that whichimplements methodology of the present invention described below) isloaded from the storage device or mass (fixed) storage 166 into the main(RAM) memory 152, for execution by the CPU 151. During operation of theprogram logic, the system 150 accepts user input from a keyboard 156 andpointing device 158, as well as speech-based input from a voicerecognition system (not shown). The keyboard 156 permits selection ofapplication programs, entry of keyboard-based input or data, andselection and manipulation of individual data objects displayed on thedisplay device or screen 155. Likewise, the pointing device 158, such asa mouse, track ball, pen device, or the like, permits selection andmanipulation of objects on the display screen. In this manner, theseinput devices support manual user input for any process running on thesystem.

[0049] The computer system displays text and/or graphic images and otherdata on the display device 155. Display device 155 is driven by thevideo adapter 154, which is interposed between the display device 155and the system. The video adapter 154, which includes video memoryaccessible to the CPU, provides circuitry that converts pixel datastored in the video memory to a raster signal suitable for use by acathode ray tube (CRT) raster or liquid crystal display (LCD) monitor. Ahard copy of the displayed information, or other information within thesystem 150, may be obtained from the printer 157, or other outputdevice. The printer 157 may include, for instance, an HP LaserJet®printer (available from Hewlett-Packard of Palo Alto, Calif.), forcreating hard copy images of output of the system.

[0050] The system itself communicates with other devices (e.g., othercomputers) via the network interface card (NIC) 161 connected to anetwork (e.g., Ethernet network), and/or a modem 162 (e.g., 56 K baud,ISDN, DSL, or cable modem), examples of which are available from 3Com ofSanta Clara, Calif. The system 150 may also communicate with localoccasionally-connected devices (e.g., serial cable-linked devices) viathe communication (“comm”) interface 160, which may include an RS-232serial port, a Universal Serial Bus (USB) interface, or the like.Devices that will be commonly connected locally to the comm interface160 include laptop computers, handheld organizers, digital cameras, andthe like.

[0051] IBM-compatible personal computers and server computers areavailable from a variety of vendors. Representative vendors include DellComputers of Round Rock, Tex., Compaq Computers of Houston, Tex., andIBM of Armonk, N.Y. Other suitable computers include Apple-compatiblecomputers (e.g., Macintosh), which are available from Apple Computer ofCupertino, Calif., and Sun Solaris workstations, which are availablefrom Sun Microsystems of Mountain View, Calif.

[0052] The above-described system 150 is presented for purposes ofillustrating the basic hardware underlying desktop and server computercomponents—“host” components—that may be employed in the system of thepresent invention. For purposes of discussion, the following descriptionwill present examples in which it will be assumed that there exists a“host” device which is to host a client device. The present invention,however, is not limited to any particular environment or deviceconfiguration. In particular, a client/host distinction is not necessaryto the invention, but is used to provide a framework for discussion.Instead, the present invention may be implemented in any type ofcomputer system or processing environment capable of supporting themethodologies of the present invention presented in detail below.

[0053] C. Basic system software

[0054] Illustrated in FIG. 2, a computer software system 200 is providedfor directing the operation of the computer system 150. Software system200, which is stored in system memory (RAM) 152 and on fixed storage(e.g., hard disk) 166, includes a kernel or operating system (OS) 210.The OS 210 manages low-level aspects of computer operation, includingmanaging execution of processes, memory allocation, file input andoutput (I/O), and device I/O. One or more application programs, such asclient application software or “programs” 201 (e.g., 201 a, 201 b, 201c, 201 d), including image processing software, may be “loaded” (i.e.,transferred from fixed storage 166 into memory (RAM) 152) for executionby the system 150.

[0055] Software system 200 includes a graphical user interface (GUI)215, for receiving user commands and data in a graphical (e.g.,“point-and-click”) fashion. These inputs, in turn, may be acted upon bythe system 150 in accordance with instructions from operating system210, and/or client application module(s) 201. The GUI 215 also serves todisplay the results of operation from the OS 210 and application(s) 201,whereupon the user may supply additional inputs or terminate thesession. Typically, the OS 210 operates in conjunction with devicedrivers 220 (e.g., “Winsock” driver) and the system BIOS microcode 230(i.e., ROM-based microcode), particularly when interfacing withperipheral devices. OS 210 can be provided by a conventional operatingsystem, such as Microsoft® Windows 9x, Microsoft® Windows NT, orMicrosoft® Windows 2000, all available from Microsoft Corporation ofRedmond, Wash. Alternatively, OS 210 can also be an alternativeoperating system, such as IBM OS/2 (available from IBM of Armonk, N.Y.)or Macintosh OS (available from Apple Computer of Cupertino, Calif.).

[0056] The following description focuses on an application/driver“uploader” system of the present invention implemented in a first device(e.g., system 100 described above), thereby allowing that device toinject an object (e.g., application or driver) into a second device(e.g., system 150 described above). The uploader system, whenimplemented in system 100, is a software-implemented system stored inProgram Code Flash Memory 107 for execution by Processor 106, after aloading into System Memory 105. If desired, however, theapplication/driver “uploader” system of the present invention may beimplemented in an ASIC (application-specific integrated circuit). Theapplication/driver to be injected will reside in module 111 or module107 of FIG. 1A. The communications (TCP/IP or PPP) would occur throughmodule 110 of FIG. 1A or through a COMM INTERFACE from the 32-Bit RISCARM processor (this would be a module such as 160 on FIG. 1B attached tothe ARM processor). The COMM interface would typically include an RS-232UART (Universal Asynchronous Receiver Transmitter) module.

[0057] Application/driver “uploader” system providing methodology fordynamic uploading and execution of applications and drivers betweenconnected devices

[0058] A. Introduction

[0059] The following description will present examples in which it willbe assumed that there exists a first device that is to be connected to asecond device(s), such as a digital camera device (e.g., system 100)connected to a computing device (e.g., computer system 150). To simplifythe description, one device will be referred to as a “client” device andthe other device will be referred to as a “host” device. For instance,in describing the digital camera embodiment below, the digital cameradevice is considered the “client” device and the device(s) that thedigital camera device connects to is considered the “host” device(s). Aspreviously discussed, a client or host distinction is neither necessaryto the invention nor even necessarily desirable, but merely provides aframework for discussion. The focus of the following description,therefore, is not focused on a particular hardware configuration. Notonly may the present invention be applied to a variety of disparateconfigurations, but in fact the present invention is most advantageouswhen applied to disparate configurations. The following description willfocus on the application of dialog and negotiation among two or moredevices, in accordance with the present invention. The devicesthemselves, however, may be configured in a variety of hardwareconfigurations (e.g., according to the particular needs of the userand/or vendor). Thus, the following description is for the purposes ofillustration and not limitation.

[0060] B. Design considerations

[0061] In accordance with the present invention, the following approachis adopted for supporting the dynamic uploading and execution ofapplications and drivers between (temporarily or permanently) connecteddevices. The device which is to be hosted (e.g., the “client” device)initially probes its environment to determine which device or devices itis attached to (e.g., the “host” device(s)). Once it has correctlydiscerned the relevant host or target device(s), the client deviceincludes the capability of immediately sending out (i.e., uploading) aparticular driver or application (i.e., object or file of interest) forplacement, and ultimately execution, at the host device. Once theparticular object or file of interest has been “injected” into the hostdevice and is executing, the client device may simply revert to a“listening mode” in which it waits to be told what to do (i.e., receivecommands from the application or driver which is now executing at thehost device).

[0062] This approach is particularly well-suited for devices which serveas “add-on” devices (clients) to other devices (hosts) that are“smarter,” for instance, including more processing capability and/ormemory. In this scenario, the client device enters into a dialog with adevice with more resources for the purposes of harnessing the resourcesof the host device for operating the client or add-on device. The clientdevice is, using this approach, able to start running (i.e.,driver-directed operation) immediately upon attachment to a host devicethat can be identified.

[0063] Against this backdrop, one must remain cognizant of theconstraints presented by existing devices. One must take into accountthe need for backwards compatibility, including wireline, as well aswireless, compatibility, so that a particular approach does not lock outany particular class of devices. By the same token, the approach shouldprovide forward compatibility, so that the approach is prepared forfuture devices. Therefore, the approach adopted by the present inventionis designed to be easily extended to support multiple host devices aswell as multiple communication media. Upon probing its environment, theclient device identifies all relevant host devices over all relevantcommunication media. Then, the client device enters into a dialog witheach particular host device. In a manner similar to that described abovefor a single host device, the client device uploads appropriateapplication or driver software, as appropriate, for each identified hostdevice. Upon entering the listening mode, the client device can respondto any and all requests from the multiple host devices.

[0064] For purposes of backward and forward compatibility, the preferredembodiment of the present invention supports TCP/IP protocol. “TCP/IP”or “Transmission Control Protocol/Internet Protocol” is the suite ofcommunications protocols used to connect devices on the Internet. TCP/IPuses several protocols, the two main ones being TCP and IP. TCP enablestwo hosts to establish a connection and exchange streams of data. Theprotocol guarantees delivery of data and also guarantees that packetswill be delivered in the same order in which they were sent. IPprotocol, on the other hand, deals only with packets—that is, theindividual pieces of a message transmitted over a packet-switchingnetwork. TCP/IP is built into the UNIX operating system and is used bythe Internet, making it the de facto standard for transmitting data overnetworks. Because TCP/IP has widespread support and can also run overmany different types of physical connections, it is adopted as thepreferred connectivity protocol in the preferred embodiment. In thismanner, the preferred embodiment can leverage the pre-existing low-levelprotocols that are already supported by a multitude of devices.

[0065] In addition to TCP/IP, the present invention embraces afile-based approach to object storage and handling. A “file” is acollection of data or information that has a name, or “file name.”Common examples of files include executable files which contain programcommands in an executable format, text files which containhuman-readable textual data, and binary files which contain data orinstructions in binary format. A file-based technique is a well-knownmethod for storing and transmitting information, including applicationsand drivers. Therefore, in the preferred embodiment, a file-basedapproach is adopted, including use of common file names, which areportable across a variety of different systems.

[0066] C. General system modules

[0067]FIG. 3 is a high-level block diagram illustrating anapplication/driver “uploader” system of the present invention. Asdescribed above, the system 300 includes software modules that, in apreferred embodiment, are software or ASIC (application-specificintegrated circuit) modules implemented on one device (e.g., digitalcamera device or system 100) that is to be connected to another (host)device (e.g., computing device or system 150).

[0068] The core engine or workhorse module for the system 300 is in theapplication/driver uploader (engine) module 311. This module serves todetermine what is the device(s) (i.e., host(s)) that the current device(i.e., client) is connected to. Based on this determination, the moduleis also responsible for coordinating the activities of (1) initiating acommunication session with the host(s), (2) uploading the actual objectof interest (e.g., driver or application file) onto the host device, (3)invoking execution of that object, and (4) properly terminating thecommunication session, as desired.

[0069] The application/driver uploader module 311 coexists with anotherhigh-level module, the command server module 315. Once the uploadermodule 311 has completed its overall task of injecting an application ordriver of interest, the command server module 315 serves to wait forrequests/commands from the particular application or driver and that hasjust been uploaded to the host device(s), so that the client deviceitself may operate under control of the host device(s), namely,operating in response to a given command issued from a driver executingat the host device(s).

[0070] To support the just-described high-level functionality of theuploader module 311 and the command server module 315, the system 300includes lower-level modules. Therefore, at the next to lower-level, thesystem 300 includes a PHY (physical) manager 321. This module serves asan “identifier” supporting module for the uploader module 311. Inparticular, the PHY manager 321 determines which specific device (i.e.,host(s)) is physically connected to the client device, at a given pointin time (e.g., upon first connect). Here, the PHY manager 321 isresponsible for the initial physical connection, be it wireline orwireless. In operation, the PHY manager 321 sets various internal flagsfor indicating which host device(s) it has uncovered as being physicallyconnected to the client device. These flags are reflected in a registry333, which is a repository or database storing configurationinformation. Other modules of the system 300, including the uploadermodule 311, may extract information from the registry 333 to determinewhat flags have been set by the PHY manager 321, for determining whichhost devices are currently connected. The particular host-specific stepsrequired for uploading a driver of interest to the host device may bediscerned based on the flags set by the PHY manager 321.

[0071] The uploader module 311 and the command server module 315 alsoemploy an XML parser 323. The XML parser 323 provides an internalcommunication protocol for issuing commands and transmitting data. Inthe currently-preferred embodiment, all of the commands and accompanyingdata transmitted (e.g., from driver to client device, or vice versa) arepackaged using XML syntax, which provides an extensible tag-basedapproach to wrappering data. “XML” or “Extensible Markup Language” is aspecification developed by the World Wide Web Consortium, aninternational consortium of companies involved with the Internet and theWeb. XML is a pared-down version of SGML (Standard Generalized MarkupLanguage), which is designed especially for Web documents. It allowsdesigners to create their own customized tags, enabling the definition,transmission, validation, and interpretation of data betweenapplications and between organizations. For further description of XML,see, e.g., Extensible Markup Language (XML) 1.0 specification which isavailable from the World Wide Web Consortium (www.w3.org), thedisclosure of which is hereby incorporated by reference. Thespecification is also currently available on the Internet athttp://www.w3.org/TR/REC-xml.

[0072] The following two command and response pairs are examples of theXML syntax. Command: Load Application <LoadApp> <name>ApplicationName</name> <bin> <size>1234</size> (binary data here) </bin> </LoadApp>Response: Load Application <LoadAppR> <status>0</status><handle>5678</handle> </LoadAppR> Command: Activate Application<ActivateApp> <handle>5678</handle> <priority>1</priority></ActivateApp> Response: Activate Application <AcxtivateAppR><status>0</status> </ActivateAppR>

[0073] As shown, XML may be used to provide tag-delimited commands andassociated data.

[0074] As an additional advantage, XML syntax is supported by a varietyof high-level servers. As it can be expected that client devices willoften interact with servers across the Internet, XML serves as a “glue”logic supporting communication between these devices. By adopting XMLsyntax, a given client device may communicate with a high-level serverin a more efficient manner, as XML-wrappered data may be transmittedbetween devices without the need to be converted or translated beforetransmission.

[0075] Also at the level of the XML parser 323, the system 300 includesa TCP/IP stack 325 (i.e., implementing the protocol layers that definecommunication over the Internet). This module allows the use of standardTCP and IP protocols, thereby providing a socket-based communicationinterface that is highly compliant with available operating systems(e.g., UNIX, Windows, Linux, Macintosh, PalmOS, and the like) acrossmultiple hardware platforms. By adopting TCP/IP, the client device canleverage existing connectivity protocols that are commonly found on mostdevices. In the currently-preferred embodiment, the TCP/IP stack 325 isprovided as InterNiche Portable TCP/IP Protocol Stack, version 1.6,available from InterNiche Technologies, Inc. of San Jose, Calif. (a datasheet is currently available athttp://www.iniche.com/download/datasheets.htm).

[0076] At the next to lower level, the system 300 includes a registrymanager 331 which stores state information for the system 300 in aregistry 333. Recall that the PHY manager 321 sets various status flags,for defining the current environment that the client device is connectedto. The flags are maintained as name/value pairs (e.g., Windows-likeregistry settings) in the registry 333, under control of the registrymanager 331. The registry 333 comprises a hierarchically-organized“tree” of “keys” (i.e., intermediate nodes) and “values” (i.e., leafmodes consisting of name/value pairs that may be defined). Within theregistry 333, certain keys at the root of the hierarchy are consideredwell-known and provide primary division of the tree. Intermediate keysare used to further organize the registry; the very existence of certainof these intermediate nodes has semantic meaning. The leaf nodes, i.e.,“named values”, are the primary items of focus. In this manner, theregistry 333 serves as a repository indicating what variousconfiguration settings, such as TCP/IP configuration settings, that arerequired to be set in order to communicate with a particular hostdevice.

[0077] The registry implementation in the currently-preferred embodimentsupports named-value leaves of the following types:

[0078] (1) UI32, which is 32-bit unsigned data. Some or all of these 32bits may be used and/or interpreted as seen fit by the software usingthe registry, e.g., these 32 bits might be treated as a signed 32-bitvalue, or perhaps, an unsigned 8-bit value, or the like.

[0079] (2) ASCII strings, which are 8 bits/character ASCII, terminatedby the “null character”, ‘0’.

[0080] (3) UNICODE strings, which are 16 bits/char Unicode, terminatedby the “Unicode null character”, L‘0’.

[0081] (4) Arbitrary 8-bit binary data, the length of which is stored bythe registry implementation.

[0082] The registry supports keys and named values, some of which are“permanent” and some of which are “transient”. Permanent keys are storedin client devices in such a way that they “survive” between activepower-on sessions. They are implemented in such a way that they areextremely durable over/through the most “user-abusive” (e.g., unplanned)power-downs. Transient keys are only maintained for a single power-onsession. They are typically few in number, and are most often seenmarking “current” states/preferences. Additionally, the registry maydefine certain keys and values to be “read-only”.

[0083] The system 300 includes its own a file system 335. This allowsthe system 300 to store its own applications, data, and other binaryinformation. In the currently-preferred embodiment, this is implementedas a DOS-like (e.g., MS-DOS) or UNIX-like file system, for providinglocal storage on the client device. The file system 335 may be suppliedby a real-time operating system, such as a digital camera operatingsystem; or, alternatively, it may be supplied as a stand-alonesubsystem, independent of the underlying operating system. In thecurrently-preferred embodiment, the file system 335 is USFiles® FileSystem (version 3.00.02), available from U.S. Software of Hillsboro,Oreg.

[0084] To support nonvolatile flash memory storage, the file system 335may work in conjunction with a lower-level module, the flash manager 345(or other persistent storage media, such as hard disk in). The flashmanager 345 includes logic appropriate for converting file informationinto a format appropriate for nonvolatile storage. In particular, in thepreferred embodiment, it is desirable to store application drivers andrelated information in flash memory. Thus, the flash manager 345 servesas a module for managing the hardware resources available for storingfiles.

[0085] Finally, the system 300 includes a real-time operating system341. Operating systems, which perform basic system tasks, provide aninterrupt-driven mechanism for servicing system-level requests. In thecurrently-preferred embodiment, the real-time operating system isprovided by the eCos operating system (Version 1.2.1), provided by RedHat, Inc. of Durham, N.C. Version 1.3.1 is also available.

[0086] D. Detailed description of registry

[0087] The registry defines a registry key for characterizingcommunication and connectivity to host device(s), the CONNECT/commdevkey, as follows. Key: CONNECT/commdev Type: Key Persistent: YesApplication Access: Read-only Maintenance Server Access:Read/Write/Create/Delete

[0088] Sub-keys are specified to provide the client device with specificconnectivity option information. In particular, the connectivitymanagement function of a client device uses the existence of sub-keys ofCONNECT as a “table” of possible communicating devices that may beconnected from time-to-time to the client device. This connectivitymanagement function monitors for the attachment (or “arrival”) of thedevices described by these sub-keys. For example, a client camera devicemay be designed for connection to a XYZ Corp. USB cradle and a XYZ Corp.model 560 cellular telephone. In this case, there might be sub-keys,CONNECT/XyzUsbCradle and CONNECT/XyzCell560, defined. Server maintenanceaccess provides access to certain keys and values from “remote servers”via a secure communications protocol. This access allows forpost-factory configuration and/or “final user” (re)provisioning ofclient devices.

[0089] Under foregoing sub-keys additional keys, as described below,provide necessary information to the client device on how to detect theattachment of one of these devices and, after having detected suchdevices, how to utilize the possible connectivity these devices mayprovide. Key: CONNECT/commdev/PHY Type: Key Persistent: Yes ApplicationAccess: Read-only Maintenance Server Access: Read/Write/Create/Delete

[0090] This sub-key of the CONNECT/commdev key provides the clientdevice with information germane to the detection of the attachment ofthe commdev. This attachment is detected using a response-matchingapproach, where a certain sequence of data is transmitted on theclient's physical communications link and then responses to each arecompared against known responses for a commdev. The sub-keysCONNECT/commdev/PHY/QUERY and CONNECT/commdev/PHYIRESPONSE organizethese queries/responses. Key: CONNECT/commdev/PHY/QUERY Type: KeyPersistent: Yes Application Access: Read-only Maintenance Server Access:Read/Write/Create/Delete

[0091] This sub-key of a key CONNECT/commdev/PHY organizes the queriesneeded to “sense” the attachment of commdev. Values:CONNECT/commdev/PHY/QUERY/n Type: BINARY Persistent: Yes ApplicationAccess: Read-only Maintenance Server Access: Read/Write/Create/Delete

[0092] These values are individual query-byte sequences used in the“sensing” of commdev. Each is ordered from 0 upward. The query-bytesequences are output to “sense” possible attachment of commdev.Normally, for each value CONNECT/commdev/PHY/QUERYin, there is usually acorresponding value CONNECT/commdev/PHY/RESPONSE/n. If there is no suchcorresponding value, or the value is zero length, then the “match” is“instantaneous”; the client device then proceeds to the next, if any,query/response pair. Key: CONNECT/commdev/PHY/RESPONSE Type: KeyPersistent: Yes Application Access: Read-only Maintenance Server Access:ReadlWrite/Create/Delete

[0093] This sub-key of a key CONNECT/commdev/PHY organizes the responsesneeded to “sense” the attachment of commdev. Values:CONNECT/commdev/PHY/RESPONSE/n Type: BINARY Persistent: Yes ApplicationAccess: Read-only Maintenance Server Access: Read/Write/Create/Delete

[0094] These values are individual response-byte sequences used in the“sensing” of commdev. Each is ordered from 0 upward. The response-bytesequences are looked for after the output of a query-byte sequence to“sense” possible attachment of commdev. Value: CONNECT/commdev/PHY/IdType: UI32 Persistent: Yes Application Access: Read-only MaintenanceServer Access: Read/Write/Create/Delete

[0095] This UI32 value is used to uniquely identify a commdev. Theclient device vendor administers this “global numberspace”, assigning arange of numbers to client device technology licensees. These licenseesuse them in their implementations to identify the variety ofconnectivity-providing devices that their client devices sense/support.Value: CONNECT/commdev/PHY/EffectiveBaud Type: UI32 Persistent: YesApplication Access: Read-only Maintenance Server Access:Read/Write/Create/Delete

[0096] This UI32 value is used to indicate the approximate expected,effective speed in bytes/second of a commdev's raw data channel. Thisattempts to provide a speed metric based on information known a prioriabout the underlying “data service” a commdev typically can provide.Value: CONNECT/commdev/PHY/Cost Type: UI32 Persistent: Yes ApplicationAccess: Read-only Maintenance Server Access: Read/Write/Create/Delete

[0097] This UI32 value is used as a BYTE, where 0 is the “lowest cost”and 255 is the “highest cost”. This “cost” indicates how “cheap” thecommdev's physical bearer is, i.e., there is no (or an extremelytrivial) “per minute” cost to use the communications facility. Thisattempts to provide a “generic” cost metric that may be used by certainclient devices to aid in the implementation of possible user preferencesregarding issues such as quality of images uploaded over different“cost” links.

[0098] In the registry, a CONNECT/CURR/PPP key is used to track certaincurrent run-time data, related to the client device's PPP link. Thebelow-listed subkey values may be stored. Value:CONNECT/CURR/PPP/IpAddrLocal Type: UI32 Persistent: No ApplicationAccess: Read/Write/Create/Delete Maintenance Server Access: Read-only

[0099] This value is the client device's current IP address in “networkorder”. If the value is 0×00000000, it may be assumed that the clientdevice has not been able to obtain an IP address. The client deviceapplication software, specifically the connectivity management function,creates and writes/maintains this value. Value:CONNECT/CURR/PPP/IpAddrRemote Type: UI32 Persistent: No ApplicationAccess: Read/Write/Create/Delete Maintenance Server Access: Read-only

[0100] This value is the far peer device's current IP address in“network order”. Typically, this would not be the client-supportingserver, but rather the Internet host with which the current PPP link isestablished. If the value is 0×00000000, it may be assumed that theclient device has not been able to obtain an IP address. The clientdevice application software, specifically the connectivity managementfunction, creates and writes/maintains this value. Value:CONNECT/CURR/PPP/Mtu Type: UI32 Persistent: No Application Access:Read/Write/Create/Delete Maintenance Server Access: Read-only

[0101] This value is the negotiated PPP Maximum Transmission Unit (MTU)for the currently established PPP link. If there is no established PPPlink, this value should be 0. The client device application software,specifically the connectivity management function, creates andwrites/maintains this value. Currently, this is not a required value.The client device should not create and/or maintain this value.

[0102] A CONNECT/commdev/NET key is used to organize parametricinformation related to Internet communications, for layers above PPP.Value: CONNECT/commdev/NET/Dns Type: Key Persistent: Yes ApplicationAccess: Read-only Maintenance Server Access: Read/Write/Create/Delete

[0103] This key organizes the specification of zero, one, or more DomainName Server machines on the Internet, which should be used by the IPstack to resolve fully-qualified host names. If this sub-key is notpresent, it is to be interpreted that no DNS services are needed in thecommunication configuration specified by CONNECT/commdev. If this keyexists but has no values (specifying DNS IP addresses), the systeminterpretes this to indicate that DNS information is required and thatit should be obtained using DHCP. Value: CONNECT/commdev/NET/Dns/n Type:CLsStr Persistent: Yes Application Access: Read-only Maintenance ServerAccess: Read/Write/Create/Delete

[0104] This/these values, 0 thru n, are value data (CLsStr data) thatspecify the IP address (in “dot form” address, e.g., “204.30.31.5”) of aDomain Name Server (DNS) that the client device should preferably use inmapping host names to IP addresses. These values only exist in thecommunications environment described by CONNECT/commdev only if the DNSaddress(es) must be specified a priori, e.g., there is no dynamic DNSinformation available during PPP establishment time. Value:CONNECT/commdev/NET/TcpMss Type: UI32 Persistent: Yes ApplicationAccess: Read-only Maintenance Server Access: Read/Write/Create/Delete

[0105] This UI32 value is the maximum size of a TCP transmissionsegment. Value: CONNECT/commdev/NET/TcpWindow Type: UI32 Persistent: YesApplication Access: Read-only Maintenance Server Access:Read/Write/Create/Delete

[0106] This UI32 value is the size of the TCP window in bytes. Value:CONNECT/commdev/NET/TcpKeepAlive Type: UI32 Persistent: Yes ApplicationAccess: Read-only Maintenance Server Access: Read/Write/Create/Delete

[0107] This UI32 value is used as a BOOL, where 0 is FALSE and 1 isTRUE. A value of 1 indicates that the client device will generate “idle”TCP PDUs to keep any TCP connections up.

[0108] E. Detailed description of PHY manager

[0109] The PHY manager 321 will now be described in further detail. ThePHY manager 321 probes for new devices over what the registry 333 listsas the then-current communication medium. Communication media mayinclude, for instance, wireless, serial (RS-232)wired, USB, or the like.Depending on the hardware configuration of the client device, it ispossible to have multiple communication media active simultaneously.Typically, the registry 333 includes a default (factory preset)configuration registry entry specifying the initial communication medium(or media) available upon initial power up of the client device. Forthis default connectivity entry and other connectivity entries, theregistry 333 includes corresponding default communication rates (baudrates) and corresponding handshake protocols (command set). Using thisinformation, the PHY manager 321 may execute an initial sequence ofhandshake commands and comparing any response received to a list ofknown responses for identifying a particular host device. For example,to elicit devices that may be connected via RS-232, the PHY manager 321may begin by sending out corresponding sequences of initializationcommands (e.g., AT commands), at different baud, for eliciting aresponse from any potential host that is connected. Probing for hostdevices continues until all known potential host devices have beenenumerated. Based on what is found, the PHY manager 321 updates theregistry 333 with information describing which host devices the clientdevice is currently connected to.

[0110] In order to illustrate how the PHY manager 321 determines whathost device(s) is connected to the device under use, consider thefollowing two examples which illustrate the process used to determine ifa host is connected. Both examples will use a serial RS-232 connectionto transmit data.

EXAMPLE #1

[0111] Windows NT RRAS Server

[0112] This connection is set to emulate a serial port-to-serial portPC-to-PC connection. The first item is to set the serial port to theproper data rate. For this case, 115200 baud is the default. The nextstep is to send out a text string to the PC RAS Host. The following isthe transmission and reply for a connection session. Send: CLIENT[carriage-return] Reply: SERVER [carriage-return]

[0113] Now, the process may negotiate a PPP connection with the WindowsNT Server. PPP refers to Point-to-Point Protocol, a well-known methodfor transmission of IP packets over serial lines; see, e.g., RFC 1661:The Point-to-Point Protocol (PPP), available from the Network WorkingGroup, the disclosure of which is hereby incorporated by reference. RFC1661 is currently available via the Internet at:http://wwwfreesoft.org/CIE/RFC/1661/index.htm.

EXAMPLE #2

[0114] Modem mode of Cell Phone with internal PPP Server

[0115] This mode emulates a standard modem AT connection. For this case,the default serial port rate is 38400 baud. The following characters aresent on the serial port to determine that a modem-compatible device isconnected. Send: AT [carriage-return] Reply: OK [carriage-return]

[0116] The next step is to negotiate a PPP session with the internal PPPServer. Refer to the above-mentioned RFC 1661 for more information onnegotiating a PPP session.

[0117] The PHY manager 321 is also responsible for ensuring that anyother low-level connectivity is met such that a state of TCP/IPcommunication is reached. This is required because TCP/IP may not infact be operating at the point when the client device first initiatescommunication. For instance, in normal RS-232 serial communication andUSB communication, TCP/IP will not yet be running. Although TCP/IPconfiguration may not be yet running at the outset, Point-to-PointProtocol (PPP) may be employed to ensure TCP/IP connectivity, in amanner similar to that commonly done with dial-up Internet connections.PPP (Point-to-Point Protocol), as described above, is a protocol definedin RFC 1661 for communication between two computers using a serialinterface, such as a personal computer connected by phone line to aserver. For example, Internet Server Providers typically provide theirusers with a PPP connection so that the provider's server can respond touser requests, pass them on to the Internet, and forward requestedInternet responses back to the users.

[0118] Use of PPP is made possible due to the fact that most hosts thatsupport a TCP/IP stack will also support PPP within their TCP/IP stack.Accordingly, the client device can initiate a PPP session throughwell-known means, and thereupon request TCP/IP communication.Additionally, the client device is also capable of being a PPP server,and thereby accepting clients as well. All told, through use of theavailable PPP protocol, the client device can initiate TCP/IPconnectivity, including determining an IP address for a given hostdevice, even if TCP/IP connectivity does not exist at the outset. Inthis manner, the PHY manager 321 sets up a communication TCP/IP channelallowing the client device to communicate with the connected hostdevice(s).

[0119] F. Detail description of application/driver uploader module

[0120] The application/driver uploader module 311 will now be describedin further detail. This module acts on the information elicited by thePHY manager 321, as maintained in the registry 333, in order todetermine what tasks need to be performed, in regards to interoperatingwith host devices. Within the TCP/IP parameters stored for a given host,the registry 333 will maintain an IP address for that host. In thecurrently-preferred embodiment, the client device communicates as aTCP/IP client, not as a server. A port (logical connection) number isdefined for the host device to listen on.

[0121] Once a TCP/IP communication session is open, the applicationdriver may now be “injected” into the host device. Now, the clientdevice opens the corresponding file that contains the appropriateapplication driver (file). This request is serviced by the file system335. If the appropriate application driver exists and can be opened, thefile system 335 returns a file handle to the application/driver uploader311. The application/driver uploader 311 may now package the file fortransmission across the established TCP/IP communication medium. In thecurrently-preferred embodiment, this is accomplished by a definedinternal command sequence. At the conclusion of this portion of theprocess, the file of interest has been injected into the host device,with a corresponding file handle returned to the client device.

[0122] The file handle returned to the client supports importantclient-controlled functionality, thereby allowing the client device toaccess the file that has just been injected into the host device in avariety of ways. For example, returning this file handle to the clientdevice will allow the client device to perform a variety of operationson that file as it resides at the host device, including starting up thefile as an application or driver. In the currently-preferred embodiment,the file handle returned to the client device is any reference to thatapplication which is supported by the host device's architecture. Thismay be, for instance, a file handle provided by the host device or afile name recognized by the host device.

[0123] The final step of the process is to actually invoke execution ofthe injected application or driver. In this particular injectionscenario, therefore, the injected object is an executable file (orcapable of triggering execution of a corresponding executable file).Therefore, it includes program code, for instance, machine instructionsfor a particular target processor or byte code instructions for avirtual machine (e.g., Java byte code instructions for executing a Javavirtual machine at the host). Java is a well-known programming languagespecification, available from Sun Microsystems of Mountain View, Calif.Further description of the Java Language environment can be found in thetechnical, trade, and patent literature; see e.g., Gosling, J. et al.,The Java Language Environment: A White Paper, Sun Microsystems ComputerCompany, October 1995, the disclosure of which is hereby incorporated byreference.

[0124] In the instance where the injected application or drivercomprises byte code (e.g., Java byte code), that application or drivermay target a potentially larger number of host devices (compared to aprocessor-specific executable, which supports a smaller number ofpotential host devices). Therefore, in the currently-preferredembodiment, the application or driver to be injected comprises a Javaprogram, with the intended host, in a corresponding manner, supportingrun-time operation of a corresponding virtual machine capable ofexecuting the program byte code (e.g., Java Virtual Machine at the hostdevice capable of executing the Java program code). Although use of Javafor creating the application or driver allows one to potentially targeta larger number of host devices, those skilled in the art willappreciate that the methodology of the present invention is equallyapplicable to client-to-host object injection in both byte code andnative machine code-supported environments.

[0125] To invoke execution, the client device issues a command which,when received by the host device, triggers execution of thejust-injected application or driver. Based on the prior identificationof the host device, the uploader 311 may retrieve from the registry 333information indicating the appropriate command to issue for theidentified host device. In the straightforward case, the host device maysimply be instructed to begin execution of the injected application ordriver. For some host devices, however, execution may have to betriggered through indirect means. For example, if the host device doesnot support direct execution of the injected application or driver, itmay be possible to achieve the same result by instructing the hostdevice to “restart” itself, whereupon the injected application or driveris recognized by the host device as an object that should be invoked(i.e., so that the host device starts up with the injected applicationor driver running). Once the injected application or driver isexecuting, it is able to direct operation of the host device, includinghaving the host device issue appropriate commands to the client devicefor achieving a desired task (e.g., uploading photographs for wirelesstransmission).

[0126] Invocation of execution at the host device is perhaps bestillustrated by way of example. The following example presents a commandsequence illustrating invocation of an injected application or driver ata host device supporting the Java environment (i.e., including the JavaVirtual Machine).

EXAMPLE #1

[0127] Java environment

[0128] The following commands will start an application in the hostdevice's Java environment: Command: LoadApplication LoadApp(name =MyApp, size = (appsize), data = (binary application data)) Reply:LoadAppR(status = (pass/fail), handle = AppHand)) Command:StartApplication StartApp (handle = AppHand) Reply: StartApp(status =(pass/fail))

[0129] As result of this command sequence, the injected application isnow running on the host device's Java Virtual Machine.

EXAMPLE #2

[0130] Palm environment

[0131] The following command sequence will load an application into aPalm device. Command: LoadApplication LoadApp(name = MyApp, size =(appsize), data = (binary application data)) Reply: LoadAppR(status =(pass/fail), handle = AppHand))

[0132] The user will need to manually run the application as a normalPalm application to begin using the application. Future versions ofPalm-compatible devices may allow automatic execution, as the above Javaenvironment.

[0133] G. Summary of overall operation

[0134] Referring now to FIGS. 4A-B, the overall method or process of thepresent invention may be summarized by the following method steps. Asshown at step 401, the process gets underway upon the establishment of aconnection (wireless or wireline) between a client device and a hostdevice; the connection may be permanent or temporary. At step 402,starting with default registry information, the client device probes forany host devices. As described, this task falls specifically on the PHYmanager. Based on the information uncovered at step 402, the registry(i.e., registry 333 above) is updated, at step 403, with informationdescribing discovered host devices and corresponding communicationinformation relevant to each such discovered host device. As part ofthis step, the PHY manager will ensure TCP/IP connectivity to each suchhost device.

[0135] Now, the method may proceed with injection of the application ordriver into the host device(s). At step 404, the method may examine theregistry for determining each host device that is connected, as thiswill determine what specific task(s) must be undertaken for performinginjection (i.e., to inject an appropriate application or driver intoeach such host device). At step 405, a TCP/IP session is establishedwith the host device, for the specific purpose of injecting the file orobject of interest (e.g., application or driver). At step 406, the fileis opened on the client device; as part of this process, a client-sidefile handle is obtained. From the perspective of the client device, thefile is simply a binary object to be injected. The specific relevance ofthe file will be uncovered at the host device, when the file isultimately executed at the host device. Having obtained a valid filehandle for the file to be injected at step 406, the method may nowproceed to package the file contents for transmission to host device, asindicated at step 407. In the currently-preferred embodiment, the XMLprotocol is employed for this packaging. Now, using TCP/IP, the packagedfile may be transmitted (streamed) from the client device to the hostdevice, as indicated by step 408. In conjunction with this step, ahost-side file handle is returned to the client device.

[0136] At this point, the method is now ready to trigger execution ofthe just-injected application or driver at the host device. Using thehost-side file handle, the method instructs the host to now execute thejust-injected application or driver, as indicated by step 409. Aspreviously described, host-side execution may require host-specificoperations. In the straightforward case, the host is simply instructedto begin execution of the application or driver. If the host device doesnot support that functionality, however, execution of the application ordriver may be accomplished through indirect means, such as instructingthe host to “restart” itself and thereupon execute the application ordriver (e.g., by placing the application or driver in a location wherethe host will automatically load it for execution upon startup).Thereafter, as indicated by step 410, operation between the client andhost devices continues as specified in the now-executing application ordriver, which itself in turn may unpackage other drivers for execution.In typical operation, the application or driver would issue particularcommands to the client device, for instance, requesting that the clientdevice transmit particular information that is to be processed by thehost device (e.g., uploading digital photographs from the client deviceto the host device, for wireless transmission by the host device).

[0137] Camera to phone communications interface

[0138] A. Introduction

[0139] In accordance with the present invention, a communicationsinterface embodiment is provided between a cellular (GSM) phone, Javabytecode application, and a wireless digital camera (e.g., system 100).This interface describes all the capabilities that are required toimplement a UI application.

[0140] B. Description of channels

[0141] 1. Multi-channel communication

[0142] (a) General

[0143] The digital camera communicates with the GSM phone over amulti-channel I/O bus. This bus uses a TCP/IP-based packet protocol tosimulate multiple simultaneous communication channels over multiplesockets. Using this system, the camera software can have severalsimultaneous conversations with the phone.

[0144] The camera makes use of four supplied channels: theManagement/Monitor channel, the Event channel, the UI/Command channel,and the Server channel. A common protocol is implemented on the firstthree channels. This protocol transmits commands and replies as ASCIIXML coded data.

[0145] (b) Management/Monitor channel

[0146] The camera uses the Management channel to upload the Javabytecode application to the phone and to manipulate the application. Theapplication commands include application execution, applicationtermination, and application activation. The phone “listens” on thisport and will wait for the camera to connect to this port.

[0147] (c) Event channel

[0148] The Event channel is used to send event messages between thecamera and the phone app. One event is a “heartbeat monitor” for thephone. The phone periodically expects a heartbeat packet in response toa heartbeat request in order for it to consider the camera app stillconnected. Once a heartbeat is missed, the phone will assume that thecamera has been disengaged from the phone (or powered off) and willexecute appropriate termination sequences. This is implemented by aStatus command that returns the present camera status.

[0149] The camera “listens” on this port and accepts a connection onthis port. The camera can also query the phone to determine the presentstatus of the phone. This may help the camera determine when to enteraggressive power saving modes of operation. In addition, the camera cansend the phone a “photo done” event to indicate a new photo isavailable.

[0150] (d) UI/Command channel

[0151] The camera uses the UI channel to establish a direct line ofcommunication between the camera software resident on the camera itselfand the Java bytecode application uploaded to the phone. The camera“listens” on this port, and the Java application will connect to thecamera on this port. The command structure and state diagrams of thiscommunication are entirely determined by the camera and Java softwarepackages.

[0152] (e) Server channel

[0153] The camera uses the Server channel to establish a directcommunication with a target IP address on the cellular network (or theInternet).

[0154] C. XML protocol

[0155] The protocols used for the Management/Monitor channel, Eventchannel, and UI/Command channels consist of XML data commands andreplies. XML is used to support parsing of the command type and thecommand parameters. Because standard format tags are used, standard XMLparsers can be used to extract the command and parameter information foreach transfer.

[0156] All XML PDUs will start with a tag to indicate the version. Thistag is a 2-character value, with the first character indicating themajor revision of the PDU and the second character indicating the minorrevision of the code. The following is an example: <Ver>“01”</Ver>. Thisindicates that this is version 0.1 of the protocol.

[0157] The protocol insures that the beginning and end of the PDU can bedetermined. All XML transfers have beginning and end tags to indicatethe extent of the packet. These tags are all followed by a carriagereturn value or newline character value to indicate the end of thepresent line and the beginning of a new line. This document tagdetermines what type of command is to be performed.

[0158] In addition, commands and replies may include additionalparameters used to completely specify the command or reply. The datatypes supported by the tags are as follows:

[0159] 1. ASCII String—a group of ASCII characters. This is not NULLterminated, and does not contain a length value.

[0160] 2. UI4—a 4 byte unsigned integer as defined in XML.

[0161] 3. UI1—a 1 byte unsigned integer as defined in XML.

[0162] 4. Binary Data—a generic byte buffer. This must be preceded by asize tag to prevent false end tag values within binary data.

[0163] 5. Enum—this is a 1 byte value that is used to represent an enumequivalent value. The exact numeric value of all enum types aredocumented elsewhere. The byte is interpreted as an unsigned 8 bitvalue.

[0164] 6. Parent—a tag to indicate the start of a new hierarchy.

[0165] The default data value is a string, if not listed otherwise.Presently, all data values are either ASCII string values or BinaryData.

[0166] The parser is strict—tags must appear in the order given. Allnumbers strings must be either in decimal or C style hex format with aprepended Ox.

[0167] The following table lists the parameter tag, the tag's type, anda short description of the use of the tag: Parameter Tag TypeDescription <name></name> ASCII String Indicates the name of a file,application or photo object. <size></size> ASCII String Size in bytes ofa data object. Only associated with binary objects. <fsize></fsize>ASCII String Size in bytes of a file. <status></status> ASCII StringThis values represents the error state resulting from the execution of acommand. All states will return 0(OK), 1(ERR_BAD_CMD), 2(ERR_BAD_TAG),(3)ERR_BAD_PARAM, 4(ERR_FAILED), 5(ERR_NOT_IMPL) or a command specificerror value. <handle></handle> ASCII String A 32 bit value to be used toreference a particular application object. <dir></dir> ASCII String Astring describing the name of a directory. <priority> ASCII String Anenum to indicate the priority of the </priority> execution of thecommand: HI, NORM or LO. <date></date> ASCII String A date type that isin the following format: (Wed, 17 May 2000) <time></time> ASCII String Acharacter type that is accurate to the second. (11:02:32) <zone></zone>ASCII String A string that describes the offset from GMT time. (−0700)<utc></utc> ASCII String A string that represents the Posix UTC timevalue. This is defined as the number of seconds since 1 January, 1970.<cameraState> ASCII String An enum representing the state of the camera:</cameraState> ERROR, SLEEP, BUSY, READY. <phoneState> ASCII String Anenum representing the state of the phone: </phoneState> ERROR, SLEEP,BUSY, READY. <photoState> ASCII String An enum representing the state ofa photo: </photoState> LOCAL, TAG, SENT. <text></text> ASCII StringRepresents a text string. <width></width> ASCII String A 32 bit valuerepresenting the width of a picture object. <height></height> ASCIIString A 32 bit value representing the height of a picture object.<aspectwidth> ASCII String A float value representing the aspect widthof </aspectwidth> a picture object. This is used in conjunction with theaspectheight value. <aspectheight> ASCII String A float valuerepresenting the height of a </aspectheight> picture object. This isused in conjunction with the aspectwidth value. <depth></depth> ASCIIString An 8 bit value representing the bits per pixel of a pictureobject. The tested values are 1 and 2. <color></color> ASCII String Anenum representing the type of color mechanism used to implement thedepth. Presently the only value supported is BW. <type></type> ASCIIString A string to indicate the type of picture object. The valid valuesare alien_preview, generic, low, med, high, full, anc and tagged. NOTE:tagged is not supported by the CamGetPicture command. Anc, low, med,high are not supported by the CamGetPhotoDir command. <num></num> ASCIIString A 32 bit quantity to indicate the number of (32 bit number)elements to be returned. <bin></bin> Parent Tag This tag is used toindicate the presence of binary data. <file></file> Parent Tag This tagis used to indicate the following information is associated with aparticular file. <datetime> Parent Tag This tag indicates that thefollowing tags </datetime> describe the date, time and zone information.<email_list> Parent Tag This tag indicates the following tags describe</email_list> email addresses. <email></email> Parent Tag This tagencloses subtags to represent data for email transmission.<alias></alias> ASCII String This string is used to represent the fullname or other alias given to a particular email address. <emailadd>ASCII String A string to represent an email address. </emailadd><album_list> Parent Tag This tag indicates the following tags describe</album_list> Photo Album names. <album></album> ASCII String A stringto represent an album name.

[0168] All XML examples are presented in a consistent manner. Thispresentation will differ in one aspect from the above specification. Thesub tags of the overall command tags are indented four spaces forreadability. The following is an example of a command message PDU:<Ver>13</Ver> <LoadApp> <name>Vcam</name> <bin> <size> (value) </size>Replace (value) with actual value (data) Replace (data) with actual data</bin> </LoadApp>

[0169] D. Management/Monitor channel

[0170] The Management channel is used to discover what device isconnected to the camera, as well as perform any device-specificinitialization actions on the attached device.

[0171] The following section describes the functions available aftercommunications have been established with the phone. This communicationwill occur on Port 13000. The phone is the master of this channel andwill be accepting connections to this port.

[0172] 1. Load application

[0173] The following is the process to load the Java bytecodeapplication from the camera to the phone:

EXAMPLE #1

[0174] Camera−>Phone <LoadApp> <name> (app) </name> <bin> <size> (value)</size> The size of the data in bytes (data) The Java bytecode binarydata </bin> </LoadApp>

EXAMPLE #2

[0175] Camera<−Phone <LoadAppR> <status> (value) </status> Standarderror replies or ERR_TOO_BIG <handle> (value) </handle> A handle torepresent the app </LoadAppR>

[0176] 2. Release application

[0177] The Release Application command is sent to indicate that theapplication can be deleted from the phone. The following is the processto release control of the application loaded into the phone:

EXAMPLE #1

[0178] Camera−>Phone <ReleaseApp> <handle> (value) </handle> A handle torepresent the app </ReleaseApp>

EXAMPLE #2

[0179] Camera<−Phone <ReleaseAppR> <status> (value) </status> Standarderror replies or ERR_BAD_HAND </ReleaseAppR>

[0180] 3. Start application

[0181] To start the application, the following process should be used:

EXAMPLE #1

[0182] Camera−>Phone <StartApp> <handle> (value) </handle> A handle torepresent the app </StartApp>

EXAMPLE #2

[0183] Camera<−Phone <StartAppR> <status> (value) </status> Standarderrors or ERR_BAD_HAND, ERR_RESOURCE </StartAppR>

[0184] 4. Activate application

[0185] The following process will allow the camera to activate analready-running application and bring the main application window to theforeground:

EXAMPLE #1

[0186] Camera−>Phone <ActivateApp> <handle> (value) </handle> A handleto represent the app <priority> (value) </priority> Priority = HI, NORM,LO </ActivateApp>

EXAMPLE #2

[0187] Camera<−Phone <ActivateAppR> <status> (value) </status> Standarderror replies or ERR_BAD_HAND </ActivateAppR>

[0188] 5. Stop application

[0189] A Stop Application command will terminate an application if it isrunning. A priority value will indicate the urgency to use when stoppingthe application. To stop an executing application, the following processshould be used:

EXAMPLE #1

[0190] Camera−>Phone <StopApp> <handle> (value) </handle> A handle torepresent the app <priority> (value) </priority> Priority = HI, NORM, LO</StopApp>

EXAMPLE #2

[0191] Camera<−Phone <StopAppR> <status> (value) </status> Standarderror replies or ERR_BAD_HAND </StopAppR>

[0192] 6. Get capabilities

[0193] The following process will allow the camera to login to a devicelistening on the Management channel:

EXAMPLE #1

[0194] Camera−>Phone <GetCap> </GetCap>

EXAMPLE #2

[0195] Camera<−Phone <GetCapR> <status> (value) </status> Standard errorreplies <lang> (value) </lang> Present language (English, etc.) <id>(value) </id> id of device <imei> (value) </imei> imei of device <imsi>(value) </imsi> imsi of device <screen> (value) </screen> Displaycapabilities <version> (value) </version> Version of code <dataLink>(value) </dataLink> Quality of data link <flash> (value) </flash> Flashcapability <cpu> (value) </cpu> Standard error replies </GetCapR>

[0196] 7. Get active application handle

[0197] The Get Active Application Handle command is documented forcompleteness. There are no current plans to use this command. Thefollowing process will retrieve the handle of the currently-activeapplication running on the phone:

EXAMPLE #1

[0198] Camera−>Phone <GetActAppHandle> </GetActAppHandle>

EXAMPLE #2

[0199] Camera<−Phone <GetActAppHandleR> <status> (value) </status>Standard error replies <handle> (value) </handle> Handle to theapplication </GetActAppHandleR>

[0200] 8. Start camera application

[0201] To start the application, the following process should be used:

EXAMPLE #1

[0202] Camera−>Phone <StartCameraApp> </StartCameraApp>

EXAMPLE #2

[0203] Camera<−Phone <StartCameraAppR> <status> (value) </status>Standard errors or ERR_BAD_HAND, ERR_RESOURCE </StartCameraAppR>

[0204] E. Event channel

[0205] The Event channel is a bi-directional channel to be used to shareevents with an attached device. Both the camera and the phone will queryeach other to determine if there are any changes in status that willaffect operation. This communication will occur on Port 13001. Thecamera listens on this port and will accept connections to this port.

[0206] 1. Status (phone)

[0207] The camera will also be capable of periodically querying thephone using a Status packet to test the phone's status. The followingprocess is used to get status on the phone:

EXAMPLE #1

[0208] Camera−>App <PhoneStatusEvent> </PhoneStatusEvent>

EXAMPLE #2

[0209] Camera<−App <PhoneStatusEventR> <status> (value) </status>Standard error replies <phoneState> (state) </phoneState> state = ERROR,SLEEP, BUSY or READY </PhoneStatusEventR>

[0210] 2. Photo done

[0211] To notify the application that a new picture has been takenduring this session, the camera will send this message to the phone:

EXAMPLE #1

[0212] Camera−>App <PhonePhotoDoneEvent> <name> (file name) </name></PhonePhotoDoneEvent>

EXAMPLE #2

[0213] Camera<−App <PhonePhotoDoneEventR> <status> (value) </status>Standard error replies </PhonePhotaDoneEventR>

[0214] 3. Photo state change

[0215] To notify the application that a photo has changed state (sent toserver) during this session, the camera will send this message to thephone:

EXAMPLE #1

[0216] Camera−>App <PhonePhotoStateEvent> <name> (file name) </name><photoState> (state) </photoState> Where state is LOCAL, TAG or SENT</PhonePhotoStateEvent>

EXAMPLE #2

[0217] Camera<−App <PhonePhotoStateEventR> <status> (value) </status>Standard error replies </PhonePhotoStateEventR>

[0218] 4. Phone message box

[0219] The following command allows the camera to send a string to thephone application. This string is then displayed in a message box to theuser. Optionally, a data entry field can be specified. To send the text,send the following:

EXAMPLE #1

[0220] Camera−>App <PhoneMessageBox> <text> (message) </text> <mboxType>(data) </mboxType> Type of Message Box to display </PhoneMessageBox>

EXAMPLE #2

[0221] Camera<−App <PhoneMessageBoxR> <status> (value) </status>Standard error replies <text> (data)</text> Optional data entered byuser </PhoneMessageBoxR>

[0222] The mboxType is a numeric ASCII value specifying the type ofmessage box to display. The only two values are 0 and 1. A static textonly message box is indicated by the value 0. A message box with asingle text entry item has a value of 1. No other values are supportedin this revision.

[0223] A user may cancel a text entry message box. The status valuereturned in the reply will indicate if the user has canceled theoperation. If the user has entered a value and has continued, the statuswill indicate OK and a text value will be returned in the reply which isthe value entered by the user. The status returns would be representedby numeric ASCII values as defined by the following C/C++ statement:typedef enum { UICHAN_OK, UICHAN_BAD_CMD, UICHAN_BAD_TAG,UICHAN_BAD_PARAM, UICHAN_FAILED, UICHAN_NOT_IMPL, UICHAN_CANCELED }UICHAN_STATUS_E;

[0224] 5. Phone server connected event

[0225] The following command tells the phone that the camera hassuccessfully connected to a photo server. This is in response to aUI/Command Channel Contact Server command. The syntax is as follows:

EXAMPLE #1

[0226] Camera−>App <PhoneServerConnectedEvent></PhoneServerConnectedEvent>

EXAMPLE #2

[0227] Camera<−App <PhoneServerConnectedEventR> <status> (value)</status> Standard error replies </PhoneServerConnectedEventR>

[0228] 6. Phone server done event

[0229] The following event tells the phone that the server has finishedits connection with the camera, and the data call can be safelyterminated. This is in response to a UI/Command Channel Contact Servercommand. The syntax is as follows:

EXAMPLE #1

[0230] Camera−>App <PhoneServerDoneEvent> </PhoneServerDoneEvent>

EXAMPLE #2

[0231] Camera<−App <PhoneServerDoneEventR> <status>(value)</status>Standard error replies </PhoneServerDoneEventR>

[0232] 7. Photo transfer event

[0233] This event tells the camera application how much of the photo hasbeen transferred. These events are sent only when a significant amountof data has been transferred from the camera. The 100% event may not besent, as there is a separate Photo State event to indicate when thephoto has been successfully transferred. The following is the syntax tosend the Photo Transfer Event:

EXAMPLE #1

[0234] Camera−>App <PhonePhotoTransferEvent> <name>(file name)<name><percent>(data)</percent> </PhonePhotoTransferEvent>

EXAMPLE #2

[0235] Camera<−App <PhonephotoTransferEventR> <status>(value)</status>Standard error replies <PhonePhotoTransferEventR>

[0236] The percent is an integer ASCII value specifying the percent ofthe photo that has been transferred.

[0237] F. UI/Command channel

[0238] This communication protocol is completely under the control ofthe camera since the camera uploads the application that willcommunicate over this channel. The following is the communications thatwill be supported between the camera and the Java bytecode application.This communication will be conducted over Port 13002. The camera is themaster of this port and will accept connections on this port.

[0239] 1. Set time

[0240] To allow the camera to synchronize time with the application, theapplication will send the camera a message to set the current time. Themessage is as follows:

EXAMPLE #1

[0241] Camera<−App <CamSetTime> <datetime> <date>Mon, 12 June,2000</date> <time>11:32:06</time> <zone>-0800</zone> <utc>16083360</utc></datetime> </CamSetTime>

EXAMPLE #2

[0242] Camera−>App <CamSetTimeR> <status>(value)</status> Standard errorreplies </CamSetTimeR>

[0243] 2. Get time

[0244] This message will allow the application to query the camera tosupport time synchronization. The process is as follows:

EXAMPLE #1

[0245] Camera<−App <CamGetTime> </CamGetTime>

EXAMPLE #2

[0246] Camera−>App <CamGetTimeR> <status>(value)</status> Standard errorreplies <datetime> <date>Mon, 12 June, 2000</date> <time>11:32:06</time><zone>-0800</zone> <utc>16083360</utc> </datetime>\n </CamGetTime

[0247] 3. Set photo state

[0248] The following process will embed the Photo State within aspecific file:

EXAMPLE #1

[0249] Camera<−App <CamSetPhotoState> <name>(photo)</name><stateType>(value)</stateType> 0 for simple, 1 for detailed<photoState>(state)</photoState> (LOCAL, TAG or SENT for simple)<photoStateDetail>(state)</photoStateDetail> (see below. Detail only)</CamSetPhotoState>

EXAMPLE #2

[0250] Camera−>App <CamSetPhotoStateR> <status>(value)</status> Standarderror replies or ERR_BAD_NAME </CamSetPhotoStateR>

[0251] The stateType value is optional. If not present, the simple statewill be returned. The simple state has three states: LOCAL, TAG or SENT.The detailed state adds one photoState to the simple photo state: DONE.The detailed photo state, photoStateDetail, returns the number of photocompartments that have been sent. This is interpreted as an ASCIIinteger value. The current design specification is for a maximum of 64compartments.

[0252] 4. Get photo state

[0253] The following process will retrieve the Photo State within aspecific file:

EXAMPLE #1

[0254] Camera<−App <CamGetPhotoState> <name>(photo)</name><stateType>(value)</stateType> 0 for simple, 1 for detailed</CamGetPhotoState>

EXAMPLE #2

[0255] Camera−>App <CamGetPhotoStateR> <status>(value)</status> Standarderror replies or ERR_BAD_NAME <photoState>(state)</PhotoState> Wherestate is LOCAL, TAG or SENT <photoStateDetail>(state)</photoStateDetail>(see below. Detail only) </CamGetPhotoStateR>

[0256] The stateType value is optional. If not present, the simple statewill be returned. The simple state has three states: LOCAL, TAG or SENT.The detailed state adds one photoState to the simple photo state: DONE.The detailed photo state, photoStateDetail, returns the number of photocompartments that have been sent. This is interpreted as an ASCIIinteger value. The current design specification is for a maximum of 64compartments.

[0257] 5. Set photo data

[0258] The following process will send ancillary photo data to thecamera for future use by the Server or the phone:

EXAMPLE #1

[0259] Camera<−App <CamSetPhotoData> <name>(photo)</name> <title>MyPicture</title> <location>Sydney Australia</location> <comments>Myfather age 64, my mother age 62</comments> <email_list>\n <email><alias>User Name</alias>\n <emailadd>user@isp.com</emailadd>\n </email><email> <alias>Mini Me</alias>\n <emailadd>me@isp.com</emailadd>\n</email> </email_list>\n <album_list> <album>Travel</album><album>Holiday</album> </album_list> </CamSetPhotoData>

EXAMPLE #2

[0260] Camera−>App <CamSetPhotoDataR> <status>(value)</Status> Standarderror replies or ERR_BAD_NAME </CamSetPhotoDataR>

[0261] 6. Get photo data

[0262] The following process will retrieve the ancillary photo data fora particular photo:

EXAMPLE #1

[0263] Camera<−App <CamGetPhotoData> <name>(photo)</name></CamGetPhotoData> <CamGetPhotoDataR> <status>(value)</status> Standarderror replies or ERR_BAD_NAME <title>My Picture</title> <location>SydneyAustralia</location> <comments>My father age 64, my mother age62</comments> <email_list> <emailadd>user@isp.com</emailadd><emailadd>me@isp.com</emailadd> </email_list> <album_list><album>Travel</album> <album>Holiday</album> </album_list></CamGetPhotoDataR>

EXAMPLE #2

[0264] Camera−>App <CamGetPhotoDataR>  <status>(value)</status>  Standard error replies or   ERR_BAD_NAME  <title>My Picture</title>   <location>Sydney Australia</location>  <comments>My father age 64, my mother age 62</comments>   <email_list>    <emailadd>user@isp.com</emailadd>    <emailadd>me@isp.com</emailadd>   </email_list>   <album_list>    <album>Travel</album>     <album>Holiday</album>   </album_list></CamGetphotoDataR>

[0265] 7. Set album

[0266] The following process will send album data to the camera forfuture use by the Server or the phone:

EXAMPLE #1

[0267] Camera<−App <CamSetAlbum> <album_list> <album>Travel</album><album>Holiday</album> </album_list> </CamSetAlbum>

EXAMPLE #2

[0268] Camera−>App <CamSetAlbumR> <status>(value)</status> Standarderror replies or ERR_BAD_NAME </CamSetAlbumR>

[0269] 8. Get album

[0270] The following process will retrieve the album data from thephone:

EXAMPLE #1

[0271] Camera<−App <CamGetAlbum> </CamGetAlbum>

EXAMPLE #2

[0272] Camera−>App <CamGetAlbumR> <status>(value)</status> Standarderror replies or ERR_BAD_NAME <album_list> <album>Travel</album><album>Holiday</album> </album_list> </CamGetAlbumR>

[0273] 9. Get picture

[0274] The following process will send a picture file from the camera tothe application. Not all parameters are required for all picture types.

EXAMPLE #1

[0275] Camera<−App <CamGetPicture> <name>(photo)</name><width>(value)</width> <height>(value)</height><aspectwidth>(value)</aspectwidth> A text representation of a float<aspectheight>(value)</aspectheight> A text representation of a float<depth>(value)</depth> The number of bits per pixel(1)<color>(value)</color The type of display (BW) <type>(value)</type> Thetype of image to retrieve (BITMAP) <startByte>(data)</startByte> Startbyte of data <fsize>(data)</fsize> Number of bytes<startPercent>(data)</startPercent> Start percent for UI events<endPercent>(data)</endPercent> End percent for UI events</CamGetPicture>

EXAMPLE #2

[0276] Camera−>App <CamGetPictureR> <status>(value)</status> Standarderror replies or ERR_BAD_NAME <bin> <size>(value)</size> Value is numberof bytes of Data (data) Data is the requested image </bin></CamGetPictureR>

[0277] The <startByte> and <fsize> values are optional. These valuesallow retrieval of partial images. If these tags are not present, thewhole file will be returned. This value only applies to nativeprogressive picture formats.

[0278] The <startPercent> and <endpercent> values are also optional.These values can be used to indicate to the camera the UV update rangefor a particular picture transfer. This allows Host to dictate to thecamera how the UI photo events will be handled.

[0279] 10. Contact server

[0280] The following process will cause the camera to initiate aconnection to a Server through the Server channel:

EXAMPLE #1

[0281] Camera<−App <CamCallServer> </CamCallServer>

EXAMPLE #2

[0282] Camera−>App <CamCallServerR> <status>(value)</status> Standarderror replies </CamCallServerR>

[0283] The reply from the camera does not indicate that the Serverconnection has been made. A separate asynchronous Server Connected eventon the Event Channel indicates when the connection has been made. AServer Done event on the Event Channel indicates when the call iscomplete. If an error occurs in connection and a connection was nevermade, a Server Done event with an error code will be sent without aServer Connected event.

[0284] A subsequent Contact Server command should not be sent before aServer Done event on the Event channel has been received from the lastContact Server command.

[0285] 11. Hangup server

[0286] The following process will cause the camera to terminate thecurrent Server connection:

EXAMPLE #1

[0287] Camera<−App <CamHangupServer> </CamHangupServer>

EXAMPLE #2

[0288] Camera−>App <CamHangupserverR> <status>(value)</status> Standarderror replies </CamHangupServerR>

[0289] The reply from the camera does not indicate that the Serverconnection has been disconnected. A separate asynchronous Server Doneevent on the Event Channel indicates when the Server connection has beenterminated.

[0290] 12. Delete rile

[0291] The following process will delete a file from the camera:

EXAMPLE #1

[0292] Camera<−App <CamFDel> <name>(value)</name> </CamFDel>

EXAMPLE #2

[0293] Camera−>App <CamFDelR> <status>(value)</status> Standard errorreplies or ERR_BAD_NAME </CamFDelR>

[0294] 13. Delete photo

[0295] The following process will delete a file from the camera:

EXAMPLE #1

[0296] Camera<−App <CamPDel> <name>(value)</name> </CamPDel>

EXAMPLE #2

[0297] Camera−>App <CamPDelR> <status>(value)</status> Standard errorreplies or ERR_BAD_NAME </CamPDelR>

[0298] 14. Photo directory

[0299] To get a listing of photos on the camera, the application willuse this process:

EXAMPLE #1

[0300] Camera<−App <CamPDir> <type>(value)</type> alien_review, full,tagged </CamPDir>

EXAMPLE #2

[0301] Camera−>App <CamPDirR> <status> (value) </status> Standard errorreplies <num> (value) </num> Number of file names <name> (file1) </name><name> (file2) </name> . . . </CamPDirR>

[0302] 15. File directory

[0303] To get a listing of files on the camera, the application will usethis process:

EXAMPLE #1

[0304] Camera<−App <CamFDir> <dir> (directory) </dir> </CamFDir>

EXAMPLE #2

[0305] Camera−>App <CamFDirR> <status> (value) </status> Standard errorreplies <num> (value) </num> Number of file names <file> <name> (file1)</name> <fsize> (size) </fsize> <date> (date) </date> </file> <file><name> (file2) </name> <fsize> (size) </fsize> <date> (date) </date></file> . . . </CamFDirR>

[0306] 16. Send file

[0307] The application can send a file (either a photo or applicationfile) to the camera. This can be used for upgrading code as well asphoto sharing. Use this process to send a file to the camera:

EXAMPLE #1

[0308] Camera<−App <CamSendFile> <name> (value) </name> Name of the file<bin> <size> (value) </sixe> Value is number of bytes of Data (data)Data is the requested image </bin> </CamSendFile

EXAMPLE #2

[0309] Camera−>App <CamSendFileR> <status> (value) </status> Standarderror replies or ERR_BAD_NAME /CamSendFileR>

[0310] 17. Get file

[0311] The following process will send a file from the camera to theapplication:

EXAMPLE #1

[0312] Camera<−App <CamGetFile> <name> (file) </name> Name of the file<startByte> (data) </startByte> Start byte of data <fsize> (data)</fsize> Number of bytes </CamGetFile>

EXAMPLE #2

[0313] Camera−>App <CamGetFileR> <status> (value) </status> Standarderror replies or ERR_BAD_NAME <bin> <size> (value) </sixe> Value isnumber of bytes of Data (data) Data is the requested image <bin></CamGetFileR>

[0314] The <startByte> and <fsize> values are optional. These valuesallow retrieval of partial files. If these tags are not present, thewhole file will be returned.

[0315] 18. Camera info

[0316] This command indicates that the user has selected a menu itemindicating they wish to view the camera information. The followingcommand and reply set specify a mechanism to indicate to the camera thatthis information has been requested. A separate Event Channel message,Phone Message Box, as described above, will be used to display theinformation for the user.

[0317] The following command indicates that the Camera Info menu itemhas been selected:

EXAMPLE #1

[0318] Camera<−App <CamInfoMenu> </CamInfoMenu>

EXAMPLE #2

[0319] Camera−>App <CamInfoMenuR> <status> (value) </status> Standarderror replies </CamInfoMenuR>

[0320] 19. Camera set sound state

[0321] This command will turn the camera sounds on or off. A parameterin the command packet will indicate if the sound will be turned on oroff. The sound state will be preserved across power cycles.

EXAMPLE #1

[0322] Camera<−App <CamSetSoundState> <soundState> (value) </soundState></CamSetSoundState>

EXAMPLE #2

[0323] Camera−>App <CamSetSoundStateR> <status> (value) </status>Standard error replies </CamSetSoundStateR>

[0324] The soundState value is an integer ASCII value specifying whetherthe sound is enabled (1) or disabled (0).

[0325] 20. Camera get sound state

[0326] This command will query the camera to determine whether thecamera sounds are on or off.

EXAMPLE #1

[0327] Camera<−App <CamGetSoundState> </CamGetSoundState>

EXAMPLE #2

[0328] Camera−>App <CamGetSoundStateR> <status> (value) </status>Standard error replies <soundState> (value) </soundState></CamGetSoundStateR>

[0329] The soundState value is an integer ASCII value specifying whetherthe sound is enabled (1) or disabled (0).

[0330] 21. File formats

[0331] The following table describes the file extensions and formatsthat are available on the camera. File Type File Extension DescriptionPhoto none The photo file is the base name for all of the filesassociated with a photo. Preview 1 none A preview image is createddynamically. Progressive Photo .ppf LightSurf proprietary photo format(described, e.g., in Format the above-mentioned 09/537,001 application).Tag File .tag This zero length file indicates that a photo is ready tobe sent to the Photo Server. Sent File .snt This zero length fileindicates that a photo has been successfully sent to the Photo Server.Ancillary Data .anc This file contains the Title, Location, Comments, E-mail address list, album, timestamp, and other items used to describethe photo image.

[0332] G. Server channel

[0333] This channel will be used to open a connection between the PhotoServer and the camera. This allows photo and file transfer between aLightSurf Server and the camera. The data sent between the camera andthe Server is completely independent of the phone. The phone will onlyforward the packets sent on this channel. The Server communications willbe based on the UI channel communications.

[0334] While the invention is described in some detail with specificreference to a single-preferred embodiment and certain alternatives,there is no intent to limit the invention to that particular embodimentor those specific alternatives. For instance, those skilled in the artwill appreciate that modifications may be made to the preferredembodiment without departing from the teachings of the presentinvention.

What is claimed is:
 1. In a computer environment where devices areoccasionally connected together, a method for automated transmission andexecution of an executable file of interest originating from a digitalcamera, upon the digital camera's connection to a cellular phone, themethod comprising: connecting the digital camera to a cellular phonecapable of hosting the camera; identifying at least one particularcellular phone that is connected to the camera, including determiningcommunication information allowing communication between the camera andthe particular cellular phone, and determining command informationallowing the camera to invoke execution of a file of interest at theparticular cellular phone; based on said determined communicationinformation, transmitting the executable file of interest from saidcamera to the particular cellular phone; and based on said determinedcommand information, invoking execution of the executable file ofinterest after it has been transmitted to the particular cellular phone.2. The method of claim 1, wherein said executable file of interestcomprises a driver file.
 3. The method of claim 2, wherein said driverfile, upon execution, controls operation of said camera.
 4. The methodof claim 1, wherein said executable file comprises a binary file havinginstructions capable of executing at said cellular phone.
 5. The methodof claim 1, wherein said executable file comprises an applicationprogram capable of executing at said cellular phone.
 6. The method ofclaim 1, wherein said camera includes an add-in device capable of beinghosted by said cellular phone.
 7. The method of claim 6, wherein saidcamera comprises a digital camera and wherein said method furthercomprises: upon execution of said executable file at said cellularphone, transferring image information from said digital camera to saidcellular phone.
 8. At the method of claim 7, further comprising: aftertransferring said image information from said digital camera to saidcellular phone, wirelessly transmitting said image information to athird device.
 9. The method of claim 1, wherein said cellular phoneincludes a computing device capable of hosting other devices.
 10. Themethod of claim 1, wherein said cellular phone includes wirelesstransmission capability for transferring information received from saidcamera to other devices.
 11. The method of claim 1, wherein said cameraand cellular phones are occasionally connected together.
 12. The methodof claim 1, wherein said camera and cellular phones are permanentlyconnected together.
 13. The method of claim 1, wherein said camera andcellular phones are connected together via a serial communication link.14. The method of claim 13, wherein said serial communication linkcomprises an RS-232 serial communication link.
 15. The method of claim1, wherein said camera and cellular phones are connected together via aUSB (Universal Serial Bus) link.
 16. The method of claim 1, whereininvocation of said identifying step occurs upon connecting said cameraand cellular phones together.
 17. The method of claim 1, wherein saididentifying step includes: probing the camera's environment fordetermining which devices, if any, the camera is attached to.
 18. Themethod of claim 17, wherein said probing step includes: determining adefault communication medium for probing for new devices.
 19. The methodof claim 18, wherein said default communication medium is specifiedinitially by factory-preset information.
 20. The method of claim 18,wherein said default communication medium is a selected one of awireless and a wired communication medium.
 21. The method of claim 20,wherein said default communication medium includes a serial (RS-232)anda USB (Universal Serial Bus) wired communication medium.
 22. The methodof claim 19, wherein said factory-preset information is stored in aregistry of the camera.
 23. The method of claim 19, wherein saidfactory-preset information includes a default communication rate anddefault handshake protocol for at least one potential cellular phone.24. The method of claim 17, wherein said probing step includes:executing an initial sequence of handshake commands and comparing anyresponse received to a list of known responses for identifying aparticular cellular phone.
 25. The method of claim 17, wherein saidprobing step continues until all known potential cellular phones havebeen enumerated.
 26. The method of claim 1, wherein said identifyingstep includes: updating a registry at said camera for indicating anyconnected cellular phone that has been identified.
 27. The method ofclaim 1, further comprising: upon identifying at least one particularcellular phone, ensuring that a state of TCP/IP communication is reachedbetween said camera and the particular identified cellular phone. 28.The method of claim 27, wherein said step of ensuring that a state ofTCP/IP communication is reached includes: initiating a PPP(Point-to-Point Protocol) communication session between said camera andcellular phones; and, thereafter initiating a TCP/IP communicationsession between said camera and cellular phones.
 29. The method of claim27, wherein said step of ensuring that a state of TCP/IP communicationis reached includes: determining an IP (Internet Protocol) address forsaid cellular phone.
 30. The method of claim 1, wherein said step oftransmitting the executable file of interest includes: opening theexecutable file of interest at the camera; and streaming the openedexecutable file of interest from the camera to the cellular phone. 31.The method of claim 30, wherein said streaming step includes: employingXML protocol for packaging said executable file of interest for deliveryto the cellular phone.
 32. The method of claim 30, wherein said step oftransmitting further comprises: returning to said camera a file handlepermitting said camera to access said executable file of interesttransmitted to said cellular phone.
 33. The method of claim 31, whereinsaid file handle comprises a file handle that may be understood by saidcellular phone for accessing a particular file of interest at saidcellular phone.
 34. The method of claim 1, wherein said executable fileof interest comprises a byte-code program, and wherein said cellularphone includes capability for executing byte-code programs.
 35. Themethod of claim 1, wherein said executable file of interest comprises aJava program, and wherein said cellular phone includes a Java VirtualMachine for executing Java programs.
 36. The method of claim 1, whereinsaid step of invoking execution of the executable file of interestincludes: issuing a command from said camera to said cellular phone tobegin execution at said cellular phone of said executable file ofinterest.
 37. The method of claim 1, wherein said step of invokingexecution of the executable file of interest includes: triggeringexecution of said executable file indirectly at said cellular phone byinstructing said cellular phone to restart itself.
 38. The method ofclaim 1, further comprising: placing said camera in a listening mode,after said camera has invoked execution of said executable file at saidcellular phone.
 39. The method of claim 38, wherein said camera awaitscommands from said cellular phone, while said camera is in a listeningmode.
 40. The method of claim 39, wherein commands received at saidcamera from said cellular phone control operation of said camera.
 41. Amulti-device system providing automated loading and execution of adriver required for connected devices, the system comprising: a camerathat may be connected to a cellular phone that is capable of hosting thecamera; and a subsystem, incorporated in the camera, for automatically:(i) identifying the cellular phone upon connection to the camera, saidsubsystem initiating communication between the two devices; (ii)uploading the driver of interest from the camera to the cellular phone;and (ii) transmitting at least one command from the camera that invokesexecution of the driver of interest at the cellular phone, whereupon thedriver executes at the cellular phone for controlling operation of thecamera.
 42. The system of claim 41, wherein said driver comprises abinary file having instructions capable of executing at said cellularphone.
 43. The system of claim 42, wherein said binary file comprisesnative machine instructions for execution by a processor at saidcellular phone.
 44. The system of claim 42, wherein said binary filecomprises byte-code instructions for execution by an interpreter at saidcellular phone.
 45. The system of claim 44, wherein said binary filecomprises a Java program, and wherein said cellular phone includes aJava Virtual Machine for executing Java programs.
 46. The system ofclaim 44, wherein said driver includes: instructions for unpacking otherexecutable files for execution at said cellular phone.
 47. The system ofclaim 41, wherein said camera comprises an add-in device capable ofbeing hosted by said cellular phone.
 48. The system of claim 47, whereinsaid camera comprises a digital camera device, and wherein said cellularphone comprises a handheld device capable of hosting said digital cameradevice.
 49. The system of claim 48, wherein said handheld computingdevice functions to retrieve digital image information from said digitalcamera device and wirelessly transmit that information to anothersystem.
 50. The system of claim 48, wherein said handheld device is aselected one of a cellular phone device and a handheld computing device.51. In a computer environment where devices are occasionally connectedtogether, a method for automated transmission, execution, andmanipulation of an executable file of interest originating from a firstdevice, upon the first device's connection to a host device, the methodcomprising: connecting the first device to at least one other devicecapable of hosting the first device; identifying at least one particularhost device that is connected to the first device, including determiningcommunication information allowing communication between the firstdevice and the particular host device, and determining commandinformation allowing the first device to manipulate and invoke executionof an executable file of interest at the particular host device; basedon said determined communication information, transmitting theexecutable file of interest from said first device to the particularhost device; based on said determined command information, transmittingfrom said first device to the particular host device commands thatmanipulate the executable file of interest at the particular hostdevice; and initiating a dialog between the two devices, including: (i)executing said commands transmitted to the host device on the hostdevice, and (ii) in response to said commands transmitted to the hostdevice, returning a reply from the host device to the first device. 52.The method of claim 51, wherein said commands include a command to loadthe executable file of interest.
 53. The method of claim 51, whereinsaid commands include a command to start the executable file ofinterest.
 54. The method of claim 51, wherein said commands include acommand to end the executable file of interest.
 55. The method of claim51, wherein said commands include a command to activate the executablefile of interest.
 56. The method of claim 51, wherein said commandsinclude a command to get the capabilities of the host device.
 57. Themethod of claim 51, wherein said commands include a command to get areference to the executable file of interest that is running on the hostdevice.
 58. The method of claim 51, wherein said executable file ofinterest comprises a Java program, and wherein said host device includesa Java Virtual Machine for executing Java programs.
 59. The method ofclaim 51, wherein said executable file of interest comprises a byte-codeprogram, and wherein said host device includes capability for executingbyte-code programs.
 60. The method of claim 51, further comprising:placing said host device in a listening mode to receive commands fromsaid first device.
 61. The method of claim 51, further comprising: aftersaid first device has transmitted a command to said host device, placingsaid first device in a listening mode to receive a reply transmittedfrom said host device.
 62. The method of claim 51, wherein said replytransmitted from the host device in response to said command from thefirst device includes status information.
 63. The method of claim 62,wherein said status information includes error information indicating anexecution state of a preceding command executed at the host device. 64.The method of claim 51, wherein transmission between the devices employsXML protocol.
 65. The method of claim 51, further comprising: returningto said first device a file handle permitting said first device toaccess said executable file of interest while it resides at said hostdevice.
 66. The method of claim 65, wherein said file handle comprises afile handle that may be understood by said host device for accessing aparticular file of interest at said host device.
 67. The method of claim51, wherein said dialog includes: issuing a load application commandfrom said first device to said host device to receive said executablefile of interest transmitted from the first device.
 68. The method ofclaim 67, wherein the load application command is transmitted from thefirst device to the host device as an XML stream with a syntax of:<LoadApp> <name> (app) </name> <bin> <size> (value) </size> (data)</bin> </LoadApp>


69. The method of claim 67, wherein the reply to the load applicationcommand is transmitted by the host device to the first device as an XMLstream with a syntax of: <LoadAppR> <status> (value) </status> <handle>(value) </handle> </LoadAppR>


70. The method of claim 51, wherein said dialog includes: issuing arelease application command from said first device to said host deviceto be able to delete said executable file of interest.
 71. The method ofclaim 70, wherein the release application command is transmitted fromthe first device to the host device as an XML stream with a syntax of:<ReleaseApp> <handle> (value) </handle> </ReleaseApp>


72. The method of claim 70, wherein a reply to the release applicationcommand is transmitted by the host device to the first device as an XMLstream with a syntax of: <ReleaseAppR> <status> (value) </status></ReleaseAppR>


73. The method of claim 51, wherein said dialog includes: issuing astart application command from said first device to said host device tobegin execution at said host device of said executable file of interest.74. The method of claim 73, wherein the start application command istransmitted from the first device to the host device as an XML streamwith a syntax of: <StartApp> <handle> (value) </handle> //Handle toapplication </StartApp>


75. The method of claim 73,wherein the reply to the start applicationcommand is transmitted by the host device to the first device as an XMLstream with the following syntax: <StartAppR> <status> (value) </status>//Standard error replies </StartAppR>


76. The method of claim 51, wherein said dialog includes: issuing a stopapplication command from said first device to said host device todiscontinue execution at said host device of said executable file ofinterest.
 77. The method of claim 76, wherein the stop applicationcommand is transmitted from the first device to the host device as anXML stream with a syntax of: <StopApp> <handle> (value) </handle><priority> (value) </priority> </StopApp>


78. The method of claim 76, wherein the reply to the stop applicationcommand is transmitted by the host device to the first device as an XMLstream with a syntax of: <StopAppR>  <status>(value)</status></StopAppR>


79. The method of claim 51, wherein said dialog includes: issuing anactivate application command from said first device to said host deviceto bring current execution of said executable file of interest to theforefront at said host device.
 80. The method of claim 79, wherein theactivate application command is transmitted from the first device to thehost device as an XML stream with a syntax of: <ActivateApp> <handle>(value)</handle>  <priority>(value)</priority> </ActivateApp>


81. The method of claim 79, wherein a reply to the activate applicationcommand is transmitted by the host device to the first device as an XMLstream with a syntax of: <ActivateAppR>  <status>(value)</status></ActivateAppR>


82. The method of claim 51, wherein said dialog includes: issuing acommand to get information about device capabilities of said hostdevice.
 83. The method of claim 82, wherein the device capabilitiescommand is transmitted from the first device to the host device as anXML stream with a syntax of: <GetCap> </GetCap>


84. The method of claim 82, wherein the reply to the get capabilitiescommand is transmitted by the host device to the first device as an XMLstream with a syntax of: <GetCapR>  <status>(value)</status> <lang>(value)<lang>  <id>(value)</id>  <imei>(value)</imei> <imsi>(value)</imsi>  <screen>(value)</screen> <version>(value)</version>  <dataLink>(value)</dataLink> <flash>(value)</flash>  <cpu>(value)</cpu> </GetCapR>


85. The method of claim 51, wherein said dialog includes: issuing acommand to get information about an active application handle for theexecutable file of interest.
 86. The method of claim 85, wherein thecommand to get information about an active application handle istransmitted from the first device to the host device as an XML streamwith a syntax of: <GetActAppHandle> </GetActAppHandle>


87. The method of claim 85, wherein a reply to the command to getinformation about an active application handle is transmitted by thehost device to the first device as an XML stream with a syntax of:<GetActAppHandleR>  <status>(value)</status>  <handle>(value)</handle></GetActAppHandleR>